RE: [sqlalchemy] models in different packages, often declaratively defined
-Original Message- From: sqlalchemy@googlegroups.com [mailto:sqlalch...@googlegroups.com] On Behalf Of Chris Withers Sent: 01 July 2010 19:17 To: sqlalchemy@googlegroups.com Subject: [sqlalchemy] models in different packages, often declaratively defined Hi All, Suppose I have packageA that defines: from sqlalchemy.ext.declarative import declarative_base Base = declarative_base() class User(Base) __tablename__ = 'user' ... Now, I have a packageB that defines: from sqlalchemy.ext.declarative import declarative_base Base = declarative_base() class Something(Base) ... I want Something to have a foreign key that points at User. How do I do that? The tables for packageA and packageB should exist in the same database (the extraction of User into packageA is just so that all our projects that need users get the same schema for the 'user' and related tables and functionality for users). I guess things could be engineered such that one MetaData instance is shared between all the bases (how would that be done though? I'd need to get the MetaData instance into each of the packages before declarative_base is called...) Moreover, how do I get all the Base's to share a _decl_class_registry? (I'm still hazy on why the information in _decl_class_registry can't go into MetaData, rather than having two registries...) Any ideas gratefully received... Chris If packageB depends on packageA, I would have packageB import the metadata or declarative Base class from packageA. Otherwise, I would create a new package, (called something like 'common'), which creates the metadata and declarative Base class. packageA and packageB would import those items from the common package. I imagine that by having a single declarative Base class, the _decl_class_registry problem will disappear. I also assume that the reason that isn't stored in the MetaData is that MetaData is an object provided by the underlying sql library, whereas 'declarative' is an extension to the ORM, and the MetaData class shouldn't know anything about it. Simon -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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] Passing multiple keys to undefer()
Hi there, The documentation for the undefer() method seems to indicate that it should be able to accept multiple positional arguments for keys, however trying this results in an error. I wanted to post this here to check I'm right in thinking this before I file a ticket. The docs give the signature as `undefer(*keys)`, but the description refers to key as singular, so I'm not sure. In any case, doing something like this results in an error: query.options(undefer(*columns)) results in an error, while this obviously does not: query.options(*[undefer(c) for c in columns]) So it's not a big deal. The stack trace I get is here: http://dpaste.org/Dpgi/ -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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] Re: Column order with declarative base
Michael Bayer wrote: I'd welcome any patches in this regard since I don't usually deal with the mixin feature. fine, how about Chris works up the unit test for it: Done and pushed back to tip with the fix. cheers, Chris -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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] Passing multiple keys to undefer()
undefer accepts *args so that you could define a path from the parent object of the query down to the child: query(Parent).options(undefer(Parent.child, Child.subchild, Subchild.someattribute)) The public docs currently don't really explain this detail, unless you were to guess that undefer() works like joinedload(), subqueryload(), etc. where we have more explicit documentation of this behavior. On Jul 2, 2010, at 7:13 AM, Oliver Beattie wrote: Hi there, The documentation for the undefer() method seems to indicate that it should be able to accept multiple positional arguments for keys, however trying this results in an error. I wanted to post this here to check I'm right in thinking this before I file a ticket. The docs give the signature as `undefer(*keys)`, but the description refers to key as singular, so I'm not sure. In any case, doing something like this results in an error: query.options(undefer(*columns)) results in an error, while this obviously does not: query.options(*[undefer(c) for c in columns]) So it's not a big deal. The stack trace I get is here: http://dpaste.org/Dpgi/ -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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 sqlalch...@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: Convert type from dbapi description
Michael, thanks for your help.
sorry, I dont have any context here. Are you looking for this ?
For some reason I can't reply to this thread on google news, yet I can
do with gmane newsgroups :-/
engine = create_engine('...')
Integer().get_dbapi_type(engine.dialect.dbapi) ?
that will give you the DBAPI type object.
I have tried that and this is what I've got
ipdb engine.dialect.dbapi
module 'MySQLdb' from '/usr/lib/pymodules/python2.6/MySQLdb/__init__.pyc'
ipdb meta.tables['City'].columns['ID']
Column(u'ID', INTEGER(display_width=11), table=City, primary_key=True,
nullable=False)
ipdb meta.tables['City'].columns['ID'].type
INTEGER(display_width=11)
ipdb
meta.tables['City'].columns['ID'].type.get_dbapi_type(engine.dialect.dbapi)
DBAPISet([0, 1, 3, 4, 5, 8, 9, 13])
ipdb
I don't understand why this is giving me back a DBAPISet instead of a
the native database datatype equivalent to Integer.
On Jul 1, 2010, at 7:48 AM, meitham wrote:
I am in a similar situation where I would like to have access to the
native database type.
the other question is why do you need the typing information if the
application has been working so far without it ?
I am building an XML file that can be used for a proprietary ETL tool
and I am using sqlalchemy to read the database metadata.
Since every database store their table information in tables, my other
option would be reading the type information directly from these
tables. Although I wish sqlalchemy would do that for me :-/
Meitham
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalch...@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] Re: Convert type from dbapi description
On Jul 2, 2010, at 6:10 AM, Meitham wrote:
Michael, thanks for your help.
sorry, I dont have any context here. Are you looking for this ?
For some reason I can't reply to this thread on google news, yet I can
do with gmane newsgroups :-/
engine = create_engine('...')
Integer().get_dbapi_type(engine.dialect.dbapi) ?
that will give you the DBAPI type object.
I have tried that and this is what I've got
ipdb engine.dialect.dbapi
module 'MySQLdb' from '/usr/lib/pymodules/python2.6/MySQLdb/__init__.pyc'
ipdb meta.tables['City'].columns['ID']
Column(u'ID', INTEGER(display_width=11), table=City, primary_key=True,
nullable=False)
ipdb meta.tables['City'].columns['ID'].type
INTEGER(display_width=11)
ipdb
meta.tables['City'].columns['ID'].type.get_dbapi_type(engine.dialect.dbapi)
DBAPISet([0, 1, 3, 4, 5, 8, 9, 13])
ipdb
I don't understand why this is giving me back a DBAPISet instead of a
the native database datatype equivalent to Integer.
I haven't seen a DBAPISet before, it seems to be an object that represents
multiple MySQL type codes at once.
It's not clear what kind of typing information you're looking for or what form
it would take.
On Jul 1, 2010, at 7:48 AM, meitham wrote:
I am in a similar situation where I would like to have access to the
native database type.
the other question is why do you need the typing information if the
application has been working so far without it ?
I am building an XML file that can be used for a proprietary ETL tool
and I am using sqlalchemy to read the database metadata.
Since every database store their table information in tables, my other
option would be reading the type information directly from these
tables. Although I wish sqlalchemy would do that for me :-/
Meitham
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalch...@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 sqlalch...@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: Column order with declarative base
On Jul 1, 2010, at 8:24 PM, Michael Bayer wrote: The Column object contains a sort key when constructed, against a single global value, that is used as a sort key when the Table is generated. This is to get around the fact that the attribute dictionary of the declarative class is unordered. Interesting. I guess I didn't come across this in the source. I actually ended up implementing a similar thing in a subclass I have of column (I think I'm doing some stuff that isn't very standard) Since we're talking about columns, I also noticed that copy() doesn't copy the .info object over. The mixin columns should copy their sort key over, or it should somehow be tailored in the declarative base so that the order of the two columns stays relatively the same, and perhaps is also tailored to be at the same position relative to the other columns in the ultimate table. I'd welcome any patches in this regard since I don't usually deal with the mixin feature. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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.
