[Lift] Re: Mapper Decimal, PostgreSQL, and foreign keys issues
I can take care of #1 and #3 if you can open issues for them on GitHub. If you could attach a standalone project for #3 that I can test against that would be very helpful. Derby has some other not so fun quirks with types (BINARY support sucks), so I wouldn't be surprised if there's something ridiculous in it's decimal support as well :(. I think that we should probably look at changing to H2 for the archetypes. For #1, is there a particular database that you're aware of that doesn't support SQL DECIMAL types? I only tested against PostgreSQL and MySQL when I wrote it. Derek On Sun, Aug 9, 2009 at 12:48 PM, Kyle Goodwin goodw...@gmail.com wrote: Hello, I'm fairly new to Lift, but I have found what I think are some issues in Mapper. If these have been discussed before or this isn't the proper place to bring them up please let me know: 1. MappedDecimal should use the DriverType framework to determine the type name in fieldCreatorString rather than hardcoding it in the class. 2. The PostgreSQL DriverType should be set up so that it is brokenAutogeneratedKeys but not wickedBrokenAutogeneratedKeys since it does support the RETURNING method of getting keys just not the jdbc3 method. 3. MappedDecimal seems to be truncating the fractional portions of values when using an embedded Derby database (the default archetype- generated setup). Switching to PostgreSQL resulted in normal behavior with no other changes. 4. Should the default for supportsForeignKeys_? really be false? None of the drivers seem to define this as true and most (almost all?) of them do actually support foreign keys. Foreign keys are not generated for PostgreSQL at the moment, for example, but it definitely supports them. Has this been done intentionally because foreign keys are undesired or not working? If they are undesired then it would be nice to have a straightforward way to override that setting...currently I think it would be difficult since the DriverType class for the database is loaded inside the Mapper code without an opportunity to pass in a class that overrides the default for the jdbc driver you're using. Thanks, Kyle Goodwin --~--~-~--~~~---~--~~ 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: Mapper Decimal, PostgreSQL, and foreign keys issues
I'm not aware of any database that doesn't support DECIMAL under that name however all the other Mapped types specify their type names in the DriverType declarations including things that never vary between drivers, so I just figured that was the right place for it. It doesn't matter functionally to me, just seemed to be the Right Thing. I'll make tickets on GitHub, thanks for letting me know about that, I didn't know if that was where we should report these things or what. Thanks, Kyle On Aug 10, 10:37 am, Derek Chen-Becker dchenbec...@gmail.com wrote: I can take care of #1 and #3 if you can open issues for them on GitHub. If you could attach a standalone project for #3 that I can test against that would be very helpful. Derby has some other not so fun quirks with types (BINARY support sucks), so I wouldn't be surprised if there's something ridiculous in it's decimal support as well :(. I think that we should probably look at changing to H2 for the archetypes. For #1, is there a particular database that you're aware of that doesn't support SQL DECIMAL types? I only tested against PostgreSQL and MySQL when I wrote it. Derek On Sun, Aug 9, 2009 at 12:48 PM, Kyle Goodwin goodw...@gmail.com wrote: Hello, I'm fairly new to Lift, but I have found what I think are some issues in Mapper. If these have been discussed before or this isn't the proper place to bring them up please let me know: 1. MappedDecimal should use the DriverType framework to determine the type name in fieldCreatorString rather than hardcoding it in the class. 2. The PostgreSQL DriverType should be set up so that it is brokenAutogeneratedKeys but not wickedBrokenAutogeneratedKeys since it does support the RETURNING method of getting keys just not the jdbc3 method. 3. MappedDecimal seems to be truncating the fractional portions of values when using an embedded Derby database (the default archetype- generated setup). Switching to PostgreSQL resulted in normal behavior with no other changes. 4. Should the default for supportsForeignKeys_? really be false? None of the drivers seem to define this as true and most (almost all?) of them do actually support foreign keys. Foreign keys are not generated for PostgreSQL at the moment, for example, but it definitely supports them. Has this been done intentionally because foreign keys are undesired or not working? If they are undesired then it would be nice to have a straightforward way to override that setting...currently I think it would be difficult since the DriverType class for the database is loaded inside the Mapper code without an opportunity to pass in a class that overrides the default for the jdbc driver you're using. Thanks, Kyle Goodwin --~--~-~--~~~---~--~~ 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: Mapper Decimal, PostgreSQL, and foreign keys issues
Thanks. I agree that it would be better to put that kind of thing in DriverTypes, but I wanted to check to make sure that there weren't any exceptions that I should specialize when I do put it in place. Derek On Mon, Aug 10, 2009 at 1:00 PM, Kyle Goodwin goodw...@gmail.com wrote: I'm not aware of any database that doesn't support DECIMAL under that name however all the other Mapped types specify their type names in the DriverType declarations including things that never vary between drivers, so I just figured that was the right place for it. It doesn't matter functionally to me, just seemed to be the Right Thing. I'll make tickets on GitHub, thanks for letting me know about that, I didn't know if that was where we should report these things or what. Thanks, Kyle On Aug 10, 10:37 am, Derek Chen-Becker dchenbec...@gmail.com wrote: I can take care of #1 and #3 if you can open issues for them on GitHub. If you could attach a standalone project for #3 that I can test against that would be very helpful. Derby has some other not so fun quirks with types (BINARY support sucks), so I wouldn't be surprised if there's something ridiculous in it's decimal support as well :(. I think that we should probably look at changing to H2 for the archetypes. For #1, is there a particular database that you're aware of that doesn't support SQL DECIMAL types? I only tested against PostgreSQL and MySQL when I wrote it. Derek On Sun, Aug 9, 2009 at 12:48 PM, Kyle Goodwin goodw...@gmail.com wrote: Hello, I'm fairly new to Lift, but I have found what I think are some issues in Mapper. If these have been discussed before or this isn't the proper place to bring them up please let me know: 1. MappedDecimal should use the DriverType framework to determine the type name in fieldCreatorString rather than hardcoding it in the class. 2. The PostgreSQL DriverType should be set up so that it is brokenAutogeneratedKeys but not wickedBrokenAutogeneratedKeys since it does support the RETURNING method of getting keys just not the jdbc3 method. 3. MappedDecimal seems to be truncating the fractional portions of values when using an embedded Derby database (the default archetype- generated setup). Switching to PostgreSQL resulted in normal behavior with no other changes. 4. Should the default for supportsForeignKeys_? really be false? None of the drivers seem to define this as true and most (almost all?) of them do actually support foreign keys. Foreign keys are not generated for PostgreSQL at the moment, for example, but it definitely supports them. Has this been done intentionally because foreign keys are undesired or not working? If they are undesired then it would be nice to have a straightforward way to override that setting...currently I think it would be difficult since the DriverType class for the database is loaded inside the Mapper code without an opportunity to pass in a class that overrides the default for the jdbc driver you're using. Thanks, Kyle Goodwin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
