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 lists....painful). 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 -~----------~----~----~----~------~----~------~--~---
