[Lift] Re: Proposed internal changes on Mapper?
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 dchenbec...@gmail.comwrote: I'll go ahead and see what I can do, then. Derek On Tue, Aug 18, 2009 at 11:40 AM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Aug 18, 2009 at 7:12 AM, Derek Chen-Becker dchenbec...@gmail.com 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 liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Proposed internal changes on Mapper?
On Tue, Aug 18, 2009 at 7:12 AM, Derek Chen-Becker dchenbec...@gmail.comwrote: 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 liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Proposed internal changes on Mapper?
I'll go ahead and see what I can do, then. Derek On Tue, Aug 18, 2009 at 11:40 AM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Aug 18, 2009 at 7:12 AM, Derek Chen-Becker dchenbec...@gmail.comwrote: 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 liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
