Alex, it was basically just always using named-parameters.
So instead of: execute_reader("select * from users where id = ?", 1)
You'd use: execute_reader("select * from users where id = @id", :id =>
1)
That would be the big (but easy to accomodate) breaking change.
Later we could add: command.parameters << Parameter.new(:id, 1, :type
=> DO::Mysql::Types::Int32)
Obviously with some short-cuts to the driver specific types. Like
mayber Integer would map to Int32 on a 32bit arch by default, but an
Int64 on a 64bit arch. Mysql is probably a poor example of this, but
with MSSQL, Oracle, and the rest of the "enterprise" databases this
becomes more important.
-Sam
On Nov 26, 9:56 pm, "Alex Coles" <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 22, 2008 at 5:46 AM, Dan Kubb (dkubb) <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > Hi everyone,
>
> > I've seen a few messages on Twitter and a few IRC conversations about
> > people wanting DataMapper to have JDBC drivers so they could use it
> > with jRuby. I just wanted to gauge interest in the community and see
> > if anyone interested in working on this.
>
> > Alex Coles (myabc) started on this earlier in the year, but due to
> > other obligations wasn't able to finish it up. More recently Paul
> > Lamb (plamb) has been doing some work on it too although he too is a
> > bit short on time atm. I've heard there's alot of other people who
> > would like to help but aren't really sure where to begin.
>
> > In a brief conversation with Alex on IRC today he pointed me to a
> > couple of old threads on the subject with some blockers:
>
> > http://is.gd/8wrh "Support for JRuby?"
> > http://is.gd/8wr2 "DataObjects + JDBC?"
>
> > It looks like one of the blockers has to do with just making the
> > existing DO drivers support prepared statements using a consistent
> > API, and then updating the DataObjectsAdapter in DM to use that
> > syntax. Unfortunately one of thepastielinks that Sam posted appears
> > to be a dead link now.. Sam, if you're watching would you mind chiming
> > in on the syntax you envisioned for this?
>
> Per my previous message, hopefully Sam can dig out what he had
> envisioned. I will search for some proposed examples of API changes
> that I had come up with.
>
> > The other blocker with ThreadStopErrors in Extlib::Pooling has
> > actually been mostly resolved by Dirkjan recently in my extlib fork:
> >http://github.com/extlib/dkubb. When I run the specs in that fork
> > with jRuby there's only two failures, and one of those is relatively
> > minor.
>
> > On a related note, the DM fork we're working on for the spec/doc
> > rewrite (dkubb/dm-core) passes with jRuby today using the InMemory
> > adapter.
>
> Its a relief that the TreadStopErrors look like they've been overcome.
> Headius (Charles Nutter) has offered support from the JRuby team if we
> need expertise in the area of threading.. if we can come up with a
> list of issues/questions/doubts (if there are any now) and throw them
> his way, then that would be a way forward.
>
> The fact that the InMemory adapter is also working well in JRuby means
> that once DO support is working, then we should not be far off from
> working support throughout the Merb+DO stack.
>
> Alex
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"DataMapper" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/datamapper?hl=en
-~----------~----~----~----~------~----~------~--~---
