[sqlalchemy] On creating new SchemaItems
Hello,
I would like SQLAlchemy to generate views much in the same way it can generate
tables- perhaps like this:
View('bob',select([...]))
Is the SQLAlchemy code modular enough to support a user-defined SchemaItem or
does that require changes to SQLAlchemy itself?
The reason I would very much like this is because I currently use the Table
objects, munge them through a processor to add common attributes, and generate
a schema- I would like to be able to do the same with View objects.
I looked at subclassing sqlalchemy.schema.Table, but the __new__ override and
the fact that the sql.compiler.DDLCompiler has hardcoded
visit_create_schemaitem names gives me pause as to whether or not this can be
accomplished without modifying SQLAlchemy itself.
I realize that questions surrounding view pop up from time-to-time, so does it
make sense to create or support a dialect-specific or user-defined SchemaItem?
Thanks!
Cheers,
M
--
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.
Re: [sqlalchemy] On creating new SchemaItems
On Jan 21, 2011, at 12:56 PM, A.M. wrote:
Hello,
I would like SQLAlchemy to generate views much in the same way it can
generate tables- perhaps like this:
View('bob',select([...]))
Is the SQLAlchemy code modular enough to support a user-defined SchemaItem or
does that require changes to SQLAlchemy itself?
The reason I would very much like this is because I currently use the Table
objects, munge them through a processor to add common attributes, and
generate a schema- I would like to be able to do the same with View objects.
I looked at subclassing sqlalchemy.schema.Table, but the __new__ override and
the fact that the sql.compiler.DDLCompiler has hardcoded
visit_create_schemaitem names gives me pause as to whether or not this can
be accomplished without modifying SQLAlchemy itself.
I realize that questions surrounding view pop up from time-to-time, so does
it make sense to create or support a dialect-specific or user-defined
SchemaItem?
Thanks!
You may not be aware that we have a full API for creation of custom SQL
expression subclasses as well as establishing compilation rules, which is
documented at http://www.sqlalchemy.org/docs/core/compiler.html .
Regarding views specifically, we've got a usage recipe against this system,
though I don't know if its seen any real world usage, at
http://www.sqlalchemy.org/trac/wiki/UsageRecipes/Views . Its using lower-case
table() objects as the core structure, which is your basic thing with a bunch
of columns object, the superclass of Table that doesn't have the hard linkages
with MetaData or constraints, so no SchemaItem subclass is needed. Subclassing
TableClause (the result of table()) would be the likely way to go if you wanted
your view construct to have extra features.
Cheers,
M
--
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.
--
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.
Re: [sqlalchemy] On creating new SchemaItems
On Jan 21, 2011, at 1:36 PM, Michael Bayer wrote:
On Jan 21, 2011, at 12:56 PM, A.M. wrote:
Hello,
I would like SQLAlchemy to generate views much in the same way it can
generate tables- perhaps like this:
View('bob',select([...]))
Is the SQLAlchemy code modular enough to support a user-defined SchemaItem
or does that require changes to SQLAlchemy itself?
The reason I would very much like this is because I currently use the Table
objects, munge them through a processor to add common attributes, and
generate a schema- I would like to be able to do the same with View objects.
I looked at subclassing sqlalchemy.schema.Table, but the __new__ override
and the fact that the sql.compiler.DDLCompiler has hardcoded
visit_create_schemaitem names gives me pause as to whether or not this can
be accomplished without modifying SQLAlchemy itself.
I realize that questions surrounding view pop up from time-to-time, so does
it make sense to create or support a dialect-specific or user-defined
SchemaItem?
Thanks!
You may not be aware that we have a full API for creation of custom SQL
expression subclasses as well as establishing compilation rules, which is
documented at http://www.sqlalchemy.org/docs/core/compiler.html .
Regarding views specifically, we've got a usage recipe against this system,
though I don't know if its seen any real world usage, at
http://www.sqlalchemy.org/trac/wiki/UsageRecipes/Views . Its using
lower-case table() objects as the core structure, which is your basic thing
with a bunch of columns object, the superclass of Table that doesn't have
the hard linkages with MetaData or constraints, so no SchemaItem subclass is
needed. Subclassing TableClause (the result of table()) would be the likely
way to go if you wanted your view construct to have extra features.
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?
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?
Cheers,
M
--
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.
Re: [sqlalchemy] On creating new SchemaItems
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.
