OK, changes have been added to 1.0.1-SNAPSHOT (and deployed on scala-tools.org) and I'll roll them into 1.1-SNAPSHOT (along with the Oracle and PostgreSQL fixes) this afternoon.
Derek On Tue, Aug 18, 2009 at 3:16 PM, Derek Chen-Becker <[email protected]>wrote: > I'll go ahead and see what I can do, then. > > Derek > > > On Tue, Aug 18, 2009 at 11:40 AM, David Pollak < > [email protected]> wrote: > >> >> >> On Tue, Aug 18, 2009 at 7:12 AM, Derek Chen-Becker <[email protected] >> > wrote: >> >>> I'm trying to fix Mapper support for Oracle and I've run into an issue. >>> Oracle's JDBC drivers support returning autoGenerated keys, but not the way >>> that Lift expects. The way that Lift currently works, it just calls >>> executeUpdate with Statement.RETURN_GENERATED_KEYS set. In Oracle, this will >>> simply return the ROWID of the inserted row, which means that we would have >>> to do a second select to get the actual value. Alternatively, Oracle does >>> support fetching the inserted value from a column if you use the >>> executeUpdate(String, Array[String]) method (the Array is a set of column >>> names to fetch). What I'm getting at is that support for autogenerated keys >>> is very driver-specific right now, but the DriverTypes class essentially is >>> just using some flags to control behavior in MetaMapper. I'm wondering if it >>> would make more sense to move the support for insert queries into >>> DriverTypes so that we have things tied directly to the drivers instead of >>> splitting it up between two files. I'm thinking of adding something like: >>> >>> def performUpdate(conn : Connection, stmt : String, primaryKeyColumn : >>> String) >>> def performUpdate(conn : Connection, stmt : PreparedStatement, >>> primaryKeyColumn : String) >>> >>> to DriverTypes, which would then allow us to define driver-specific key >>> fetching in place. I could move the base functionality into DriverTypes >>> itself, and then we could override as needed on specific vendor classes. The >>> current situation with flags for brokenAutogeneratedKeys_? and >>> wickedBrokenAutogeneratedKeys_?, while amusingly named, feels untenable in >>> the long term as we continue to find corner cases for vendor drivers. I >>> could add a "notQuiteBrokenButDifferentAutogeneratedKeys_?" flag for Oracle, >>> but that doesn't feel right. Thoughts? >> >> >> I think it's a good idea. It will also help with Record support for JDBC. >> >> >>> >>> >>> Derek >>> >>> >>> >> >> >> -- >> Lift, the simply functional web framework http://liftweb.net >> Beginning Scala http://www.apress.com/book/view/1430219890 >> Follow me: http://twitter.com/dpp >> Git some: http://github.com/dpp >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" 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/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
