[sqlalchemy] Re: Comparable ColumnDefaults for shema diffing
On Thursday 12 June 2008 22:44:25 Yannick Gingras wrote: Greeting Alchemists, in order to implement schema diffing, it would be nice if two similar ColumnDefault objects would be comparable as such. I attach a path to implement such test. Would it make sense to add this support in Alchemy's core or should a schema diffing library add it through monkey patching? dont rely on things having __eq__, as it may not be your notion of what equality is (type/value/metadata/whatever). u may use SA to traverse the tree as it knows best what the structure is but do all the comparisons yourself. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Comparable ColumnDefaults for shema diffing
Michael Bayer [EMAIL PROTECTED] writes: can't the schema diff utility include a function such as compare_defaults(a, b) ? a ColumnDefault isn't really like a SQL expression object so the __eq__()/__ne__() seems inappropriate (in general, overriding __eq__() is an endeavor to be taken on carefully, since it heavily changes the behavior of that object when used in lists and such). You are right that defining __eq__() can have nasty side effects but it seems strange to me that ColumnDefault(20) == ColumnDefault(20) is False. If you think that there might be other side effect that I didn't foresee, I will implement the comparator in the diffing library. It the same way, what do you think about __eq__() for types? This is False: types.Integer(10) == types.Integer(10) which was unexpected to say the least but there might be a good reason for it. -- Yannick Gingras --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Comparable ColumnDefaults for shema diffing
On Jun 12, 2008, at 5:01 PM, Yannick Gingras wrote: Michael Bayer [EMAIL PROTECTED] writes: can't the schema diff utility include a function such as compare_defaults(a, b) ? a ColumnDefault isn't really like a SQL expression object so the __eq__()/__ne__() seems inappropriate (in general, overriding __eq__() is an endeavor to be taken on carefully, since it heavily changes the behavior of that object when used in lists and such). You are right that defining __eq__() can have nasty side effects but it seems strange to me that ColumnDefault(20) == ColumnDefault(20) is False. If you think that there might be other side effect that I didn't foresee, I will implement the comparator in the diffing library. It the same way, what do you think about __eq__() for types? This is False: types.Integer(10) == types.Integer(10) which was unexpected to say the least but there might be a good reason for it. it's just that these objects weren't intended for direct expression usage. I don't override __eq__() lightly, and it does create a lot of burden within the source base (such as, we need to use the non-native OrderedSet to represent ordered collections of Columns, not plain listspainful). At the moment it seems like the comparsion of schema elements is specific to schema tools which are doing some kind of coarse-grained compare() operation. I don't yet see the comparison of granular schema elements to be of general use. I'm sure you've already written a compare_columns() function since Column cannot be compared via __eq__() either. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
