On Jan 21, 2011, at 3:15 PM, A.M. wrote: >> > > I guess I am curious as to why there should be a "built-in" way to compile > SchemaItems and then a "user" way to do the same thing. Is there a plan to > unify these methods?
I've considered it but haven't drawn a picture of what that would really look like. The decorator approach seems appropriate for ad-hoc constructs that aren't part of the "core" group of constructs, whereas the core hierarchy of Compiler classes feels more appropriate for supplying the kind of variability we see in different database SQL implementations. Perhaps what's at play here is that Compiler subclasses handle variability in DBAPI/SQL interaction, whereas decorators handle variability in sets of supported constructs. But this would all be better addressed if someone wanted to propose what the unified system would look like, including specifics to both the base Compiler and SQLCompiler classes, as well as a few dialects like the MySQL and PG dialects. I definitely do not want user-defined structures requiring the construction of a separate Compiler or CompilerExtension class, however, this is too cumbersome and is the opposite of the direction we are headed in SQLA 0.7. So a system whereby all of the dozen or so dialect implementations no longer have Compiler subclasses, the Compiler and SQLCompiler classes themselves no longer define SQL strings and likely become "final" (i.e. not usually subclassed), would be what it looks like. It would involve rewriting about 50% of each dialect. Ultimately both systems use the same dispatch function, though it is optimized in the case of builtins to have fewer method calls (which is also critical). > > As a python programmer, it seems more natural to me to subclass the relevant > class than to spam my class with decorators. Does it make sense to offer > user-defined SchemaItems which would play well with metadata much like there > are user-defined types? Not sure where you're getting the notion of "spamming a class with decorators" - which class specifically would have decorators ? The compiler system requires the construction of the ClauseElement subclass separate from the functions that define its SQL compilation, which have no class-bound requirement. Also SchemaItem is actually a separate inheritance chain than that of ClauseElement. SchemaItem subclasses don't have SQL representations, such as a ForeignKeyConstraint. Its the CreateConstraint and DropConstraint elements, ultimately descending from ClauseElement, that define a SQL representation. As far as MetaData, we offer event-based interaction such that "create" and "drop" events can be intercepted. The other purpose of MetaData is to serve as a registry of tables so that they are addressable by ForeignKey objects. If further levels of registry behavior are proposed along with their use cases we can consider them for inclusion. -- 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.
