[sqlalchemy] Re: postgres and/or generic enum support in sqlalchemy
from my perspective my comments on the ticket still stand - the MySQL specificness has to be removed and the interface regarding encoding and such should be simplified.The MySQL import and __supported business should be removed as well - I know the Interval type is doing the same thing with a dialect-specific import, but that one is wrong too - there is a better approach in the 0.6 branch. MySQL's MSEnum would be present in the dialect's colspecs dictionary as Enum:MSEnum. For Postgresql, we'd also add PGEnum and place that in PG's colspecs dict.I would prefer this to be an 0.6 thing but it can likely be backported to 0.5 without much difficulty. On May 27, 2009, at 11:07 AM, Damian wrote: Hi, http://www.sqlalchemy.org/trac/ticket/1109 Is this still being worked on? In particular it would be interesting to get this running for postgres for us. If not, I would like to have a go at it in the near future, or am happy to help test if someone else is working on this. Cheers, Damian --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: postgres and/or generic enum support in sqlalchemy
Agreed - it makes more sense to have a generic enum type which may fall back to software should the db not actually support it. Having said that, in terms of using (selecting/updating) an enum field the syntax should be quite similar across implementations. While I'm not familiar with databases other than mysql/pg it would seem that aside from the syntax for creating an enum and getting the values that compose an enum there wouldn't have to be anything dialect specific for it. Would it, based on the above assumption, not be possible to have a generic enum type that figures out what to do based on what type of database we are connected to without needing to specify MSEnum or the currently ficticious PGEnum? Or is this what you are suggesting and I have misunderstood it? If it comes in 0.6, thats fine by me - we can work around it for now. As it stands SQLAlchemy is probably one of the most awesome libraries i've ever worked with :). Damian On Wed, May 27, 2009 at 4:49 PM, Michael Bayer mike...@zzzcomputing.comwrote: from my perspective my comments on the ticket still stand - the MySQL specificness has to be removed and the interface regarding encoding and such should be simplified.The MySQL import and __supported business should be removed as well - I know the Interval type is doing the same thing with a dialect-specific import, but that one is wrong too - there is a better approach in the 0.6 branch. MySQL's MSEnum would be present in the dialect's colspecs dictionary as Enum:MSEnum. For Postgresql, we'd also add PGEnum and place that in PG's colspecs dict.I would prefer this to be an 0.6 thing but it can likely be backported to 0.5 without much difficulty. On May 27, 2009, at 11:07 AM, Damian wrote: Hi, http://www.sqlalchemy.org/trac/ticket/1109 Is this still being worked on? In particular it would be interesting to get this running for postgres for us. If not, I would like to have a go at it in the near future, or am happy to help test if someone else is working on this. Cheers, Damian --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: postgres and/or generic enum support in sqlalchemy
On May 27, 2009, at 12:09 PM, Dimmich Damian wrote: Would it, based on the above assumption, not be possible to have a generic enum type that figures out what to do based on what type of database we are connected to without needing to specify MSEnum or the currently ficticious PGEnum? Or is this what you are suggesting and I have misunderstood it? that's what im suggesting, since that's how all of our regular types work anyway. You specify String, when it comes time to do something database specific it imports PGString or similar. 0.6 has scaled down the need for dialect-specific types but the concept is the same. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: postgres and/or generic enum support in sqlalchemy
Great :). So, what needs doing to get Enum support? The ticket, which is part of the 0.5.5 roadmap mentions adding tests, would having tests be sufficient for getting it into 0.5.5? Is it still worth writing a posgres/enum PGEnum type for 0.5.x and integrating it with the patch that is in the ticket above? I have no idea how hard it would be to modify 0.5 to support an enum type in a databases colspecs.. It would seem that the approach in the ticket would be able to expose the same interface in 0.5/0.6 even if the internals changed. Cheers, Damian On Wed, May 27, 2009 at 5:22 PM, Michael Bayer mike...@zzzcomputing.comwrote: On May 27, 2009, at 12:09 PM, Dimmich Damian wrote: Would it, based on the above assumption, not be possible to have a generic enum type that figures out what to do based on what type of database we are connected to without needing to specify MSEnum or the currently ficticious PGEnum? Or is this what you are suggesting and I have misunderstood it? that's what im suggesting, since that's how all of our regular types work anyway. You specify String, when it comes time to do something database specific it imports PGString or similar. 0.6 has scaled down the need for dialect-specific types but the concept is the same. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: postgres and/or generic enum support in sqlalchemy
On May 27, 2009, at 12:39 PM, Dimmich Damian wrote: Great :). So, what needs doing to get Enum support? The ticket, which is part of the 0.5.5 roadmap mentions adding tests, would having tests be sufficient for getting it into 0.5.5? tests plus the cleanup discussed. Is it still worth writing a posgres/enum PGEnum type for 0.5.x and integrating it with the patch that is in the ticket above? I have no idea how hard it would be to modify 0.5 to support an enum type in a databases colspecs.. It would seem that the approach in the ticket would be able to expose the same interface in 0.5/0.6 even if the internals changed. the approach is more or less the same for 0.5 and 0.6. Yes, there would be a PGEnum in the postgres.py module. Cheers, Damian On Wed, May 27, 2009 at 5:22 PM, Michael Bayer mike...@zzzcomputing.com wrote: On May 27, 2009, at 12:09 PM, Dimmich Damian wrote: Would it, based on the above assumption, not be possible to have a generic enum type that figures out what to do based on what type of database we are connected to without needing to specify MSEnum or the currently ficticious PGEnum? Or is this what you are suggesting and I have misunderstood it? that's what im suggesting, since that's how all of our regular types work anyway. You specify String, when it comes time to do something database specific it imports PGString or similar. 0.6 has scaled down the need for dialect-specific types but the concept is the same. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
