Support for JRuby?
Martin
the works? Thanks in advance...
-Martin
John W Higgins
John
Martin
-M
On Jun 7, 2:51 pm, "John W Higgins" <wish...@gmail.com> wrote:
> Someone is working at least on a generic JDBC driver which should at least
> get things moving in the right direction.
>
> John
>
Alexander Coles
I am working on JDBC support. Actually it won't be a completely
generic JDBC driver - instead, I'm working to make the existing driver
gems (do_mysql, do_sqlite3, do_postgres) work with JRuby
transparently, as well as add some drivers other for popular databases.
By transparent, I mean (just as when you install a gem like Hpricot):
'gem install do_mysql' on MRI installs the C Ruby extension
and 'jruby -S gem install do_mysql' on JRuby installs the Java/JDBC-
based extension
I am working on a branch right now, but will merge in when I am
further advanced.
Initially I was looking to go the generic JDBC driver route, but
despite the fact there is plenty of shared code, there are still
dialect differences. Thanks to ior3k, who helped point me to this way
of doing things -- I think its much better to go the route that I've
just described.
Help and ideas are appreciated.
Alex
Martin
Quick question... Do you have any sort of estimate (even if it's a
rough one) on when you expect to do the merge? Thanks in advance...
Cheers,
Martin
Alexander Coles
> Hi Alex,
>
> Quick question... Do you have any sort of estimate (even if it's a
> rough one) on when you expect to do the merge? Thanks in advance...
>
> Cheers,
>
> Martin
>
Hi Martin,
I've already begun merging in some of the code. There is now
preliminary support within the DataObjects repo for the Derby embedded
database, and MySQL is next on my list. This code is at a point now
where it can be reviewed, tested, etc.
Right now I am working on making the installation/testing workflow
painless - so we can start to get people using it. And as stated,
MySQL will be priority after that.
One of the big unfinished areas (and not showing up as a failure) is
handling of date/time/timestamps. I am not intimately acquainted with
java.util.Calendar and all of the Java/Ruby date-time classes, so I
will have to get to grips with that - although help in this area would
be gladly appreciated.
Finally, support needs to be written within DataMapper -- what I've
just mentioned is all at the DataObjects API level. I'd love to get on
this this weekend but we'll see how that goes!
Do you have any particular area you think should be prioritized!
Alex
Dusan
progress?
Stephen Bannasch
>On Jun 13, 2008, at 12:01 AM, Martin wrote:
>
>> Hi Alex,
>>
>> Quick question... Do you have any sort of estimate (even if it's a
>> rough one) on when you expect to do the merge? Thanks in advance...
>>
>> Cheers,
>>
>> Martin
>>
>
>Hi Martin,
>
>I've already begun merging in some of the code. There is now
>preliminary support within the DataObjects repo for the Derby embedded
>database, and MySQL is next on my list. This code is at a point now
>where it can be reviewed, tested, etc.
Hi Alex,
This is just FYI:
I spent some time on the active record jdbc adaptors for derby and hsqldb trying to resolve these issues -- perhaps you some of these issue might affect your work.
http://jira.codehaus.org/browse/JRUBY-1960
activerecord-jdbc-derby: text column option :limit => 32000 doesn't work
http://jira.codehaus.org/browse/JRUBY-1905
ALTER TABLE failure using jdbcderby during rails migration adding a column with 'not null' constraint
The problem with JRUBY-1960 is that Derby won't insert a string longer than 32k chars into a database -- you need to use prepared statements.
I have a kludge which should work (but doesn't yet) but I found that the Java db H2 doesn't have these problems and have started using that as my Java version of a db like sqlite3.
I'd like to be able to put together an Ruby app running all on Java using JRuby so I can easily deploy to heterogeneous collection of systems.
I'd planned to look at DataMapper and am interested in your progress.
I might take a look at getting H2 to work with DataMapper.
Dan Kubb (dkubb)
prepared statements yet, but it is something on the TODO list. I
believe it's slated for after the 1.0 release though.
Dan
(dkub)
Alexander Coles
On Jun 19, 2008, at 8:17 PM, Stephen Bannasch wrote:
> Hi Alex,
>
> This is just FYI:
>
> I spent some time on the active record jdbc adaptors for derby and
> hsqldb trying to resolve these issues -- perhaps you some of these
> issue might affect your work.
>
> http://jira.codehaus.org/browse/JRUBY-1960
> activerecord-jdbc-derby: text column option :limit => 32000 doesn't
> work
>
> http://jira.codehaus.org/browse/JRUBY-1905
> ALTER TABLE failure using jdbcderby during rails migration adding a
> column with 'not null' constraint
> The problem with JRUBY-1960 is that Derby won't insert a string
> longer than 32k chars into a database -- you need to use prepared
> statements.
Hi Stephen,
Thanks for the heads-up on these issues. Its really appreciated.
Actually, I am working on an attempt to rework Command#execute_reader
to use java.sql.PreparedStatement behind the scenes.. this would save
having to write a bunch of methods for quoting different Ruby types
according to differing SQL dialects - and instead let
PreparedStatement and the JDBC driver sweat it...
> I have a kludge which should work (but doesn't yet) but I found that
> the Java db H2 doesn't have these problems and have started using
> that as my Java version of a db like sqlite3.
Yeah both Derby and HSQLDB have their own idiosyncrasies, perhaps H2
has worked around some of the problems in HSQLDB? - that make life
difficult. Examples are the inability to set max rows received in
Derby in the SQL (although I believe setMaxRows() works), and HSQLDB
not wanting to provide a resultset of keys it just inserted/updated.
> I'd like to be able to put together an Ruby app running all on Java
> using JRuby so I can easily deploy to heterogeneous collection of
> systems.
>
> I'd planned to look at DataMapper and am interested in your progress.
>
> I might take a look at getting H2 to work with DataMapper.
Please do feel free to help - at this point, help would be very much
appreciated. I'd be happy to talk you through (either on list, off-
list, or on IRC, etc.) in more detail what I've done so far, to make
it easier for you to get going writing an H2 DM driver.
Cheers,
Alex
Alexander Coles
>
> Hi Alex, will you notify us in this thread in case there will be some
> progress?
Sure. Contributions are welcome too!
Alexander Coles
Dan,
do you have any idea what DO support for prepared statements might
look like?
As mentioned in my previous reply, I am currently working (in a branch
-- can push out to a fork, if anyone is interested) on making
Command#execute_reader use java.sql.PreparedStatement. This gives us a
whole bunch of quoting and type handling behaviour for free. There are
a few problems to work around - one biggie of which is that Nil is its
own class in Ruby, so we're unable to map a suitable JDBC type for it
without some information.
Alex
Martin
Cheers,
Martin
On Jun 19, 4:50 pm, Alexander Coles <alex.co...@gmail.com> wrote:
> On Jun 19, 2008, at 10:38 PM, Dan Kubb (dkubb) wrote:
>
>
>
Sam Smoot
The eventual API for DO will include named Parameters with Type
information. So continuing down the ADO-alike route.
command = connection.create_command("SELECT * FROM users WHERE id =
@id OR (id <> @id AND name = @name)")
command.parameters.add("@name", String)
command.parameters.add("@id", Integer)
command.execute_reader('bob', 1)
Notice how the parameters are passed once to execute_reader, mapping
to the order they were added. The order in which they appear in the
query and the number of times they appear doesn't matter.
With this we can support both prepared statements, and parameterized
queries transparently. MSSQL supports the latter, but not the former
for example. Most of the databases support one or the other, but not
both as far as I'm aware.
This is definitely a post 1.0 feature however.
-Sam
Alexander Coles
On Jul 22, 2008, at 7:02 PM, Sam Smoot wrote:
>
>
>
> On Jul 22, 11:37 am, Martin <mlongo.demandb...@gmail.com> wrote:
>> I was just wondering if there has been any progress on this front?
>>
>> Cheers,
>>
>> Martin
>>
> I haven't myself.
>
> The eventual API for DO will include named Parameters with Type
> information. So continuing down the ADO-alike route.
>
> command = connection.create_command("SELECT * FROM users WHERE id =
> @id OR (id <> @id AND name = @name)")
>
> command.parameters.add("@name", String)
> command.parameters.add("@id", Integer)
>
> command.execute_reader('bob', 1)
>
> Notice how the parameters are passed once to execute_reader, mapping
> to the order they were added. The order in which they appear in the
> query and the number of times they appear doesn't matter.
>
> With this we can support both prepared statements, and parameterized
> queries transparently. MSSQL supports the latter, but not the former
> for example. Most of the databases support one or the other, but not
> both as far as I'm aware.
>
> This is definitely a post 1.0 feature however.
>
> -Sam
I'd love to see this pushed up to something targeted for 1.0 (I don't
mind putting in some hours on it), as it would make JDBC support
(backed by java.sql.PreparedStatements) a hell of a lot easier. Right
now, I began working on a branch (http://github.com/sam/do/tree/jdbc-use-ps
) but its kludge-code, and I hit a hiatus about a month ago, because
a) I didn't really want to continue knowing that better parameterized
queries would be on the way, and b) general time pressure with other
(unfortunately non-open source) work on the go.
Alex
Alexander Coles
On Jul 22, 2008, at 7:02 PM, Sam Smoot wrote:
>
>
>
> On Jul 22, 11:37 am, Martin <mlongo.demandb...@gmail.com> wrote:
>> I was just wondering if there has been any progress on this front?
>>
>> Cheers,
>>
>> Martin
>>
I will try to get back to doing some work to where DO just generates
dynamic statements (and forget backing using JDBC PreparedStatements),
which should get a basic 'proof-of-concept' solution up and running
sooner rather than later. This is something that I could target for
early August, provided I talk my way out of a few other projects!
Alex
Sam Smoot
It's not a big undertaking. It just needs to be done consistently
against all the existing drivers. Here's basically what would need to
be called when the command#execute_* methods are called:
http://pastie.textmate.org/private/5phbeybfscibjhwi0wjamq
So after that's done, we'd just need to update the DataObjectsAdapter
to add the named-parameters to queries.
Then DM and DO are prepped to allow drivers to implement prepared or
parameterized statements as they see fit.
For example, an MSSQL driver would then have the information it needs
to pass to sp_execute_sql, which, with no other changes, will cache
execution plans transparently, making them (95%) as fast as stored-
procedures.
Prepared Statements would be a little tougher since the number that
can be used is limited, so to get the most use out of them, we'd need
an LFU cache. (http://en.wikipedia.org/wiki/Cache_algorithms) so we
could set a max-size and expire the rest.
Or an LFU+LRU cache, say with an 80/20 split, plus a buffer for
tracking simple statistics to ensure the cache doesn't simply reject
new entries once it's full. Some reasonable time-based expiration
probably wouldn't hurt either.
Anyways, the point is, this doesn't need to happen all at once. Baby-
steps. The API update is most important. After that, I imagine Java
would have some nice implementations of appropriate caches, so
supporting prepared statements in the JRuby drivers would probably be
pretty easy.
-Sam