I've merged wip-dcb-mapper-datetime into master and I'll close ticket #12. Derek
On Thu, Jun 4, 2009 at 1:54 PM, Derek Chen-Becker <dchenbec...@gmail.com>wrote: > I just checked in some code in the wip-dcb-mapper-datetime branch on > e9a2f3f85e99e5e4f53611e6892830b9878d4f9a. I've tested with Derby, H2, MySQL > and PostgreSQL, so I'm pretty confident that this is working. I have a > little test project that someone could use if they want to test against > Oracle or SQL Server. > > Derek > > > On Wed, Jun 3, 2009 at 9:08 PM, David Pollak < > feeder.of.the.be...@gmail.com> wrote: > >> >> >> On Wed, Jun 3, 2009 at 3:56 PM, Derek Chen-Becker >> <dchenbec...@gmail.com>wrote: >> >>> I'm looking at issue #12: >>> >>> http://github.com/dpp/liftweb/issues#issue/12 >>> >>> I think I've tracked it down to an issue with the way Mapper handles date >>> and time data. Mapper doesn't use setTimestamp anywhere for prepared >>> statements, only setDate or setObject. The issue is that SQL Dates really >>> are just dates, not date + time. In particular, MappedDateTime's >>> jdbcFriendly and real_convertToJDBCFriendly methods are returning >>> java.sql.Dates, when they really should return java.sql.Timestamps. Also, >>> DB.runQuery uses a setDate instead of setTimestamp when the passed parameter >>> type is java.util.Date, and MetaMapper's BySql clause uses java.sql.Date. >>> The MetaMapper.save method uses st.setObject to set field values when >>> inserting and/or updating, and passes the java.sql.Types parameter >>> (TIMESTAMP, for MappedDateTime), but Derby is discarding the time portion. >>> This may also be a bug in Derby, but I don't think that we should be using >>> java.sql.Date for a TIMESTAMP field, either. Unless anyone has objections, I >>> propose that: >>> >>> >>> 1. The jdbcFriendly and convert_real... methods on MappedDateTime be >>> changed to return java.sql.Timestamp instead of java.sql.Date >>> 2. Change the BySQL clause to use a setTimestamp for the parameter if >>> the passed data is java.sql.Timestamp or java.util.Date, and use setDate >>> only if the passed data is already java.sql.Date. That way people can be >>> more explicit about which type they actually want >>> 3. Make a similar change to DB.runQuery's parameter handling >>> 4. Add a MappedDate and MappedTime for people who explicitly only >>> want a Date or Time respectively >>> >>> Thoughts? I'll go ahead and get this done this week unless anyone can >>> explain why we wouldn't want to do this. >> >> >> Sounds like a great analysis. Looking forward to the fixes. >> >> >>> >>> >>> 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 -~----------~----~----~----~------~----~------~--~---
