[sqlalchemy] need 0.6_beta2-compat declarative meta
Hi All,
In 0.6_beta2, the following code is not properly adding a primary key Column
via DeclarativeMeta which calls my PrimaryKey() function:
def PrimaryKey(seqprefix):
return Column(Integer, Sequence(seqprefix, optional=True),
primary_key=True)
class ClassDefaults(DeclarativeMeta):
def __init__(cls,classname, bases, dict_):
seqprefix = getattr(cls,'__tablename__',None)
dict_['id'] = PrimaryKey(seqprefix=seqprefix)
return DeclarativeMeta.__init__(cls, classname, bases, dict_)
Base = declarative_base(metaclass=ClassDefaults)
class Location(Base):
__tablename__ = 'location'
parent_id = Column(Integer, ForeignKey('location.id'))
parent = relation('Location', backref=backref('children'),
remote_side='location.c.id')
name = UniqueString(25)
desc = Column(String(80))
SQLAlchemy 0.6_beta2 complains on table initialization:
File /usr/lib64/python2.6/site-packages/sqlalchemy/orm/mapper.py, line 444,
in _configure_pks
key columns for mapped table '%s' % (self, self.mapped_table.description))
sqlalchemy.exc.ArgumentError: Mapper Mapper|Location|location could not
assemble any primary key columns for mapped table 'location'
This worked under 0.6_beta1 (and likely earlier versions of SQLAlchemy).
Can someone send me some code similar to above that works with 0.6_beta2, or is
this a bug in beta2?
Thanks,
Daniel
--
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] recommended declarative method design pattern for sessions
On Mar 23, 2010, at 9:29 AM, King Simon-NFHD78 wrote: object_session does indeed return the session that the instance is already bound to (so you shouldn't close it). I didn't know what object_session would return if the original session had been closed, so I tried it: Thanks for looking into this for me. As an update, I have been trying to use object_session but have been struggling with bugs related to the session returned from object_session() turning to None, presumably because it is somehow getting garbage collected. Because of this, I am going to try to use scoped_session() as this seems to be the preferred method for keeping things simple and reliable with session sharing between disparate pieces of code. This way, all my code can create a new session but will end up getting the same session, thus solving the complexity of grabbing the current object's session (I hope.) -Daniel -- 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: need 0.6_beta2-compat declarative meta
In a metaclass's __init__, the attributes have already been placed on
the class, so mutating the attributes dict has no effect.
Try setting the id attribute directly:
self.id = PrimaryKey(...)
On Mar 27, 6:04 pm, Daniel Robbins drobb...@funtoo.org wrote:
Hi All,
In 0.6_beta2, the following code is not properly adding a primary key Column
via DeclarativeMeta which calls my PrimaryKey() function:
def PrimaryKey(seqprefix):
return Column(Integer, Sequence(seqprefix, optional=True),
primary_key=True)
class ClassDefaults(DeclarativeMeta):
def __init__(cls,classname, bases, dict_):
seqprefix = getattr(cls,'__tablename__',None)
dict_['id'] = PrimaryKey(seqprefix=seqprefix)
return DeclarativeMeta.__init__(cls, classname, bases, dict_)
Base = declarative_base(metaclass=ClassDefaults)
class Location(Base):
__tablename__ = 'location'
parent_id = Column(Integer, ForeignKey('location.id'))
parent = relation('Location', backref=backref('children'),
remote_side='location.c.id')
name = UniqueString(25)
desc = Column(String(80))
SQLAlchemy 0.6_beta2 complains on table initialization:
File /usr/lib64/python2.6/site-packages/sqlalchemy/orm/mapper.py, line
444, in _configure_pks
key columns for mapped table '%s' % (self,
self.mapped_table.description))
sqlalchemy.exc.ArgumentError: Mapper Mapper|Location|location could not
assemble any primary key columns for mapped table 'location'
This worked under 0.6_beta1 (and likely earlier versions of SQLAlchemy).
Can someone send me some code similar to above that works with 0.6_beta2, or
is this a bug in beta2?
Thanks,
Daniel
--
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: need 0.6_beta2-compat declarative meta
avdd wrote:
In a metaclass's __init__, the attributes have already been placed on
the class, so mutating the attributes dict has no effect.
Spot on. SA fudged this prior to 0.6beta so you could get away with
shoving stuff in dict_, you now can't...
def PrimaryKey(seqprefix):
return Column(Integer, Sequence(seqprefix, optional=True),
primary_key=True)
class ClassDefaults(DeclarativeMeta):
def __init__(cls,classname, bases, dict_):
seqprefix = getattr(cls,'__tablename__',None)
When are you expecting cls not to have a tablename?
Using tabs for intentation is evil.
dict_['id'] = PrimaryKey(seqprefix=seqprefix)
Why not just have:
cls.id = Column(Integer, Sequence(cls.__tablename__, optional=True),
primary_key=True)
?
You might also benefit from reading:
http://www.sqlalchemy.org/docs/reference/ext/declarative.html#mix-in-classes
...I don't think they'll help here 'cos you're computing based on
__tablename__.
Of course, nowadays, I tend to have tablename computed in a mix-in that
does all my common stuff:
class BaseMixin(object):
__table_args__ = {'mysql_engine':'InnoDB'}
@classproperty
def __tablename__(cls):
return cls.__name__.lower()
id = Column(Integer,primary_key=True)
cheers,
Chris
--
Simplistix - Content Management, Batch Processing Python Consulting
- http://www.simplistix.co.uk
--
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: tightening contraints on whats allowed in mixins
Hi Michael, I read http://www.sqlalchemy.org/trac/ticket/1751 with some curiousity. My take on declarative mixins was that _as_declarative should basically accumulate everything from the bases as if it were in the class itself and then let _as_declarative behave exactly as it usually did on the resultant attributes. As such, I can't see why relationships or foreign keys in columns are a bad thing. You can have multiple classes with a relationship to a single other class, so why not allow that relationship to be abstracted out in a mixin? (DRY and all that...) cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- 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] use of dict_ versus getting attributes from cls
Hi Again, I'm also curious about use of dict_ versus getting from cls in _as_declarative. IIRC, at pycon, you changed it so that DeclarativeMeta passes the class's __dict__ as dict_ and then made it so that only dict_ is consulted for attributes. However, _as_declarative intrinsically needs to futz with cls for things like __mapper__, __table__ and __tablename__, which, iirc, was always retrieved from cls, even before the declarative mixins stuff was done. I'm wondering why _as_declarative doesn't just take a cls and it then get everything from the cls itself? I remember backwards compatability for some use that Grok makes of this, but it should be a one-liner for them to change and 0.6 would seem like a good boundary to do it... What am I missing? Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- 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] 'NoneType' object has no attribute '_sa_iterator' exception
Hi all! I'm running SQLAlchemy 0.6b2 for a while and i've seem some strange exception (AttributeError: 'NoneType' object has no attribute '_sa_iterator') happening one in a while. This is my stacktrace: Traceback (most recent call last): File /usr/lib/python2.5/threading.py, line 486, in __bootstrap_inner self.run() File /usr/lib/python2.5/threading.py, line 446, in run self.__target(*self.__args, **self.__kwargs) File ./db/models/job.py, line 109, in run func(self) File ./queue/queue.py, line 284, in job_finished job = session.merge(job) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/session.py, line 1126, in merge load=load, _recursive=_recursive) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/session.py, line 1188, in _merge prop.merge(self, state, state_dict, merged_state, merged_dict, load, _recursive) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/properties.py, line 681, in merge obj = session._merge(current_state, current_dict, load=load, _recursive=_recursive) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/session.py, line 1188, in _merge prop.merge(self, state, state_dict, merged_state, merged_dict, load, _recursive) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/properties.py, line 661, in merge for current in instances: File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/collections.py, line 570, in __iter__ return iter(getattr(self._data(), '_sa_iterator')()) AttributeError: 'NoneType' object has no attribute '_sa_iterator' I don't have a good test for this, but i'm trying to create one. Does anyone knows why this is happening? Thanks! -- Fernando Takai -- 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] 'NoneType' object has no attribute '_sa_iterator' exception
Well seems like the project you want to access is just None. SA can't do anything with it. I had a similar problem recently, it was bacause the objects got garbage collected before being accessed. A testcase would be really helpful. On Sat, 27 Mar 2010 17:42:20 +0100, Fernando Takai fernando.ta...@gmail.com wrote: Hi all! I'm running SQLAlchemy 0.6b2 for a while and i've seem some strange exception (AttributeError: 'NoneType' object has no attribute '_sa_iterator') happening one in a while. This is my stacktrace: Traceback (most recent call last): File /usr/lib/python2.5/threading.py, line 486, in __bootstrap_inner self.run() File /usr/lib/python2.5/threading.py, line 446, in run self.__target(*self.__args, **self.__kwargs) File ./db/models/job.py, line 109, in run func(self) File ./queue/queue.py, line 284, in job_finished job = session.merge(job) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/session.py, line 1126, in merge load=load, _recursive=_recursive) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/session.py, line 1188, in _merge prop.merge(self, state, state_dict, merged_state, merged_dict, load, _recursive) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/properties.py, line 681, in merge obj = session._merge(current_state, current_dict, load=load, _recursive=_recursive) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/session.py, line 1188, in _merge prop.merge(self, state, state_dict, merged_state, merged_dict, load, _recursive) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/properties.py, line 661, in merge for current in instances: File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/collections.py, line 570, in __iter__ return iter(getattr(self._data(), '_sa_iterator')()) AttributeError: 'NoneType' object has no attribute '_sa_iterator' I don't have a good test for this, but i'm trying to create one. Does anyone knows why this is happening? Thanks! -- Sebastian Elsner-pipeline td - r i s e | fx t: +49 30 20180300 sebast...@risefx.com c: +49 175 3365739 www.risefx.com r i s e | fx GmbH Schlesische Strasse 28 Aufgang B, 10997 Berlin Geschäftsführer: Sven Pannicke, Robert Pinnow Handelsregister Berlin HRB 106667 B -- 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: tightening contraints on whats allowed in mixins
On Mar 27, 2010, at 12:31 PM, Chris Withers wrote: Hi Michael, I read http://www.sqlalchemy.org/trac/ticket/1751 with some curiousity. My take on declarative mixins was that _as_declarative should basically accumulate everything from the bases as if it were in the class itself and then let _as_declarative behave exactly as it usually did on the resultant attributes. As such, I can't see why relationships or foreign keys in columns are a bad thing. You can have multiple classes with a relationship to a single other class, so why not allow that relationship to be abstracted out in a mixin? (DRY and all that...) We can fine tune the restriction to be more about specifically what was in that ticket, i.e. BaseClass(Base) some column Mixin some column with foreign key to BaseClass.some column ActualClass(BaseClass) some column that overrides BaseClass.some column issue #1. BaseClass.some column never gets bound to a table (its copied). issue #2. Mixin.some column also never gets bound to a table (its copied). it has a foreign key pointing to another non-used column. Confusing error messages ensue. issue #3. ActualClass overides BaseClass.some column completely. Even if the copies could figure out who they really need to point to in #1 and #2, they're *still* wrong - more diviniation is needed such that BaseClass.some column figures out that its bound to a class, it descends to a subclass, etc, all of this assumes a completely different paradigm of everything. #1, #2, #3 are all about Column/ForeignKey objects which are not at all aware of any of these patterns, and I'm sure there are many variants, as well as for relationship() which currently doesn't implement the copy logic.Until we can get these cases covered, I would rather that our users don't waste their time experimenting and receiving mysterious deep failures only to realize hours/days later that none of their expectations are currently covered, hence the entire field of feature is disallowed *for now*. -- 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: use of dict_ versus getting attributes from cls
On Mar 27, 2010, at 12:35 PM, Chris Withers wrote: Hi Again, I'm also curious about use of dict_ versus getting from cls in _as_declarative. IIRC, at pycon, you changed it so that DeclarativeMeta passes the class's __dict__ as dict_ and then made it so that only dict_ is consulted for attributes. I did that, I thought, because you requested that it work that way. I don't remember why you wanted it like that. However, _as_declarative intrinsically needs to futz with cls for things like __mapper__, __table__ and __tablename__, which, iirc, was always retrieved from cls, even before the declarative mixins stuff was done. I'm wondering why _as_declarative doesn't just take a cls and it then get everything from the cls itself? *shrugs*. I remember backwards compatability for some use that Grok makes of this, but it should be a one-liner for them to change and 0.6 would seem like a good boundary to do it... we should probably spend 5 minutes looking at Grok to see if there's some reason for this. -- 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: use of dict_ versus getting attributes from cls
Michael Bayer wrote: I'm also curious about use of dict_ versus getting from cls in _as_declarative. IIRC, at pycon, you changed it so that DeclarativeMeta passes the class's __dict__ as dict_ and then made it so that only dict_ is consulted for attributes. I did that, I thought, because you requested that it work that way. I don't remember why you wanted it like that. Oh, I wanted dict_ to be not used, I believe your compromise was as to pass cls.__dict__ as dict_ ;-) However, _as_declarative intrinsically needs to futz with cls for things like __mapper__, __table__ and __tablename__, which, iirc, was always retrieved from cls, even before the declarative mixins stuff was done. I'm wondering why _as_declarative doesn't just take a cls and it then get everything from the cls itself? *shrugs*. ...this was why I didn't want dict_ to be used... I remember backwards compatability for some use that Grok makes of this, but it should be a one-liner for them to change and 0.6 would seem like a good boundary to do it... we should probably spend 5 minutes looking at Grok to see if there's some reason for this. Meh, my take would be to let 'em know that it's changing in 0.6. _as_declarative is an implementation detail as far as I can see, and anyone using it directly should expect breakage and/or change at any point, not even just at 0.x boundaries... FWIW, I don't use Grok, so wouldn't have the first clue to look... Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- 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: tightening contraints on whats allowed in mixins
Michael Bayer wrote: We can fine tune the restriction to be more about specifically what was in that ticket, i.e. BaseClass(Base) some column Mixin some column with foreign key to BaseClass.some column ActualClass(BaseClass) some column that overrides BaseClass.some column For the record, this isn't the case in the ticket issue, in the ticket issue, the mixin just has a foreign key to another table, so I really can't see any problem with it. issue #1. BaseClass.some column never gets bound to a table (its copied). Sure it does, since both ActualClass and BaseClass are mapped classes, I'd expect BaseClass to map it and some kind of table inheritence to be in effect in ActualClass. That said, I'm not knowledgeable about what happens in your example, even if mixins are taken out of the equation (the mixin isn't actually used in your example, was that intentional?) issue #2. Mixin.some column also never gets bound to a table (its copied). Well, this is true since Mixin is never used, I wouldn't expect that to be true otherwise... it has a foreign key pointing to another non-used column. Confusing error messages ensue. Why are the error messages confusing? What happens in a non-declarative situation when you have a foreign key referencing a Column that isn't in a Table? (again, I'm at a disadvantage here, since I've never used SA non-declaratively...) issue #3. ActualClass overides BaseClass.some column completely. Right, in this case, I'd expect barfage, until someone volunteers the time/tests to make it otherwise... Even if the copies could figure out who they really need to point to in #1 and #2, they're *still* wrong - more diviniation is needed such that BaseClass.some column figures out that its bound to a class, it descends to a subclass, etc, all of this assumes a completely different paradigm of everything. This is a little woolly Mike ;-) #1, #2, #3 are all about Column/ForeignKey objects which are not at all aware of any of these patterns, and I'm sure there are many variants, as well as for relationship() which currently doesn't implement the copy logic.Until we can get these cases covered, I would rather that our users don't waste their time experimenting and receiving mysterious deep failures only to realize hours/days later that none of their expectations are currently covered, hence the entire field of feature is disallowed *for now*. Hmm, okay, for me, declarative is all about taking a class with attributes and turning that into a traditional mapper/table structure, right? Sure, we need to copy the columns in case they're used more than once (ie: the point of mixins!) but other than that, all the normal behaviour should apply... and if confusion ensues on the part of the user, I'd expect the error messages to be the same and as helpful as if they'd done the wrong thing non-declaratively... Again, I suspect I'm missing something huge here, but please hit me with a clue stick (or better yet, a unit test or two...) Chris PS: Thanks for giving up on svn, now I feel truly alone :-P -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- 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] 'NoneType' object has no attribute '_sa_iterator' exception
On Mar 27, 2010, at 12:42 PM, Fernando Takai wrote: Hi all! I'm running SQLAlchemy 0.6b2 for a while and i've seem some strange exception (AttributeError: 'NoneType' object has no attribute '_sa_iterator') happening one in a while. This is my stacktrace: Traceback (most recent call last): File /usr/lib/python2.5/threading.py, line 486, in __bootstrap_inner self.run() File /usr/lib/python2.5/threading.py, line 446, in run self.__target(*self.__args, **self.__kwargs) File ./db/models/job.py, line 109, in run func(self) File ./queue/queue.py, line 284, in job_finished job = session.merge(job) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/session.py, line 1126, in merge load=load, _recursive=_recursive) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/session.py, line 1188, in _merge prop.merge(self, state, state_dict, merged_state, merged_dict, load, _recursive) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/properties.py, line 681, in merge obj = session._merge(current_state, current_dict, load=load, _recursive=_recursive) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/session.py, line 1188, in _merge prop.merge(self, state, state_dict, merged_state, merged_dict, load, _recursive) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/properties.py, line 661, in merge for current in instances: File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/collections.py, line 570, in __iter__ return iter(getattr(self._data(), '_sa_iterator')()) AttributeError: 'NoneType' object has no attribute '_sa_iterator' is it possible your object is present in a session that is, in a different thread, being expired as this operation runs ? I don't have a good test for this, but i'm trying to create one. Does anyone knows why this is happening? Thanks! -- Fernando Takai -- 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.
Re: [sqlalchemy] Re: need 0.6_beta2-compat declarative meta
On Mar 27, 2010, at 5:58 AM, Chris Withers wrote:
avdd wrote:
In a metaclass's __init__, the attributes have already been placed on
the class, so mutating the attributes dict has no effect.
Spot on. SA fudged this prior to 0.6beta so you could get away with shoving
stuff in dict_, you now can't...
OK. Simply assigning something to cls.id now works. Here is my current
production code:
class ClassDefaults(DeclarativeMeta):
def __init__(cls,classname, bases, dict_):
if not ( dict_.has_key('__mapper_args__') and
dict_['__mapper_args__'].has_key('polymorphic_identity') ):
seqprefix = getattr(cls,'__tablename__',None)
cls.id = PrimaryKey(seqprefix=seqprefix)
return DeclarativeMeta.__init__(cls, classname, bases, dict_)
However, this new approach is incompatible with 0.6_beta1 (and earlier, I
assume.)
class ClassDefaults(DeclarativeMeta):
def __init__(cls,classname, bases, dict_):
seqprefix = getattr(cls,'__tablename__',None)
When are you expecting cls not to have a tablename?
The line Base = declarative_base(metaclass=ClassDefaults) requires this.
ext/declarative.py (at least in 0.6_beta1+) has a return metaclass(name,
bases, class_dict) on line 764 which causes the constructor to be called,
prior to assignment of a __tablename__. If I change my line above to seqprefix
= cls.__tablename__, I get a traceback.
Using tabs for intentation is evil.
I view choice of indentation as an issue of personal preference rather than one
that has larger moral and religious implications. I have always preferred tabs
over spaces for indent as I find them much easier to work with.
cls.id = Column(Integer, Sequence(cls.__tablename__, optional=True),
primary_key=True)
This is related to the possibility that the __tablename__ can be undefined.
When seqprefix is None, my PrimaryKey method will still return a primary key,
but it will have a unique sequence name based on a global, incrementing integer.
I do welcome any improvements to SQLAlchemy that may make this particular usage
case less complicated, but currently it appears that all my little tricks are
required.
http://www.sqlalchemy.org/docs/reference/ext/declarative.html#mix-in-classes
...I don't think they'll help here 'cos you're computing based on
__tablename__.
Right. Mix-ins look wonderful but they don't work for all cases.
Of course, nowadays, I tend to have tablename computed in a mix-in that does
all my common stuff:
class BaseMixin(object):
__table_args__ = {'mysql_engine':'InnoDB'}
@classproperty
def __tablename__(cls):
return cls.__name__.lower()
id = Column(Integer,primary_key=True)
I'm wondering if this would work for my purposes then:
class BaseMixin(object):
@classproperty
def __tablename__(cls):
return cls.__name__
id = Column(Integer, Sequence(cls.__name__, Optional=True), primary_key=True)
class Foo(Base,BaseMixin):
# will I get an id + sequence from the BaseMixin?
__name__ = foo
foo = Column(String(80), nullable=False)
Haven't tried it yet. :)
-Daniel
--
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] 'NoneType' object has no attribute '_sa_iterator' exception
is it possible your object is present in a session that is, in a different thread, being expired as this operation runs ? I don't know, but i can verify that. If that is happening, what can i do to prevent? Well seems like the project you want to access is just None. SA can't do anything with it. I had a similar problem recently, it was… I'm not trying to access anything, i'm just trying to merge the object into the session… On Sat, Mar 27, 2010 at 3:25 PM, Michael Bayer mike...@zzzcomputing.com wrote: On Mar 27, 2010, at 12:42 PM, Fernando Takai wrote: Hi all! I'm running SQLAlchemy 0.6b2 for a while and i've seem some strange exception (AttributeError: 'NoneType' object has no attribute '_sa_iterator') happening one in a while. This is my stacktrace: Traceback (most recent call last): File /usr/lib/python2.5/threading.py, line 486, in __bootstrap_inner self.run() File /usr/lib/python2.5/threading.py, line 446, in run self.__target(*self.__args, **self.__kwargs) File ./db/models/job.py, line 109, in run func(self) File ./queue/queue.py, line 284, in job_finished job = session.merge(job) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/session.py, line 1126, in merge load=load, _recursive=_recursive) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/session.py, line 1188, in _merge prop.merge(self, state, state_dict, merged_state, merged_dict, load, _recursive) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/properties.py, line 681, in merge obj = session._merge(current_state, current_dict, load=load, _recursive=_recursive) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/session.py, line 1188, in _merge prop.merge(self, state, state_dict, merged_state, merged_dict, load, _recursive) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/properties.py, line 661, in merge for current in instances: File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/collections.py, line 570, in __iter__ return iter(getattr(self._data(), '_sa_iterator')()) AttributeError: 'NoneType' object has no attribute '_sa_iterator' is it possible your object is present in a session that is, in a different thread, being expired as this operation runs ? I don't have a good test for this, but i'm trying to create one. Does anyone knows why this is happening? Thanks! -- Fernando Takai -- 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. -- Fernando Takai -- 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] reflecting (autoload=True) MySQL tinyint(1) fields
I've just discovered that some tinyint (8-bit) fields have had their values limited to 0 and 1 regardless of actual value supplied. Digging through the documentation, I've learned that when MySQL tables are reflected, tinyint(1) fields are processed as booleans. I did not find emails from others howling in pain, so I suppose most people are either happy with this behavior or unaffected. I understand why a bool column definition would be mapped to tinyint(1). However, doing the reverse, mapping tinyint(1) to bool, discards bits that MySQL would not discard. For me this was a misfeature. I would think that supplying bools to an integer field would work OK. In python 2 + True == 3. So people using booleans should not have too much difficulty, would they? Is there any chance you'd consider autoloading tinyint(1) as an integer field? -- 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] 'NoneType' object has no attribute '_sa_iterator' exception
On Mar 27, 2010, at 3:28 PM, Fernando Takai wrote: is it possible your object is present in a session that is, in a different thread, being expired as this operation runs ? I don't know, but i can verify that. If that is happening, what can i do to prevent? an object associated with a session should only be dealt with in that thread's session. session isn't threadsafe. Well seems like the project you want to access is just None. SA can't do anything with it. I had a similar problem recently, it was… I'm not trying to access anything, i'm just trying to merge the object into the session… On Sat, Mar 27, 2010 at 3:25 PM, Michael Bayer mike...@zzzcomputing.com wrote: On Mar 27, 2010, at 12:42 PM, Fernando Takai wrote: Hi all! I'm running SQLAlchemy 0.6b2 for a while and i've seem some strange exception (AttributeError: 'NoneType' object has no attribute '_sa_iterator') happening one in a while. This is my stacktrace: Traceback (most recent call last): File /usr/lib/python2.5/threading.py, line 486, in __bootstrap_inner self.run() File /usr/lib/python2.5/threading.py, line 446, in run self.__target(*self.__args, **self.__kwargs) File ./db/models/job.py, line 109, in run func(self) File ./queue/queue.py, line 284, in job_finished job = session.merge(job) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/session.py, line 1126, in merge load=load, _recursive=_recursive) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/session.py, line 1188, in _merge prop.merge(self, state, state_dict, merged_state, merged_dict, load, _recursive) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/properties.py, line 681, in merge obj = session._merge(current_state, current_dict, load=load, _recursive=_recursive) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/session.py, line 1188, in _merge prop.merge(self, state, state_dict, merged_state, merged_dict, load, _recursive) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/properties.py, line 661, in merge for current in instances: File /usr/lib/python2.5/site-packages/SQLAlchemy-0.6beta2-py2.5-linux-x86_64.egg/sqlalchemy/orm/collections.py, line 570, in __iter__ return iter(getattr(self._data(), '_sa_iterator')()) AttributeError: 'NoneType' object has no attribute '_sa_iterator' is it possible your object is present in a session that is, in a different thread, being expired as this operation runs ? I don't have a good test for this, but i'm trying to create one. Does anyone knows why this is happening? Thanks! -- Fernando Takai -- 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. -- Fernando Takai -- 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.
Re: [sqlalchemy] reflecting (autoload=True) MySQL tinyint(1) fields
On Mar 27, 2010, at 4:16 PM, Lloyd Kvam wrote: I've just discovered that some tinyint (8-bit) fields have had their values limited to 0 and 1 regardless of actual value supplied. Digging through the documentation, I've learned that when MySQL tables are reflected, tinyint(1) fields are processed as booleans. I did not find emails from others howling in pain, so I suppose most people are either happy with this behavior or unaffected. I understand why a bool column definition would be mapped to tinyint(1). However, doing the reverse, mapping tinyint(1) to bool, discards bits that MySQL would not discard. For me this was a misfeature. I would think that supplying bools to an integer field would work OK. In python 2 + True == 3. So people using booleans should not have too much difficulty, would they? Is there any chance you'd consider autoloading tinyint(1) as an integer field? sure i will remove this behavior today. -- 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.
Re: [sqlalchemy] reflecting (autoload=True) MySQL tinyint(1) fields
On Mar 27, 2010, at 5:17 PM, Michael Bayer wrote: On Mar 27, 2010, at 4:16 PM, Lloyd Kvam wrote: I've just discovered that some tinyint (8-bit) fields have had their values limited to 0 and 1 regardless of actual value supplied. Digging through the documentation, I've learned that when MySQL tables are reflected, tinyint(1) fields are processed as booleans. I did not find emails from others howling in pain, so I suppose most people are either happy with this behavior or unaffected. I understand why a bool column definition would be mapped to tinyint(1). However, doing the reverse, mapping tinyint(1) to bool, discards bits that MySQL would not discard. For me this was a misfeature. I would think that supplying bools to an integer field would work OK. In python 2 + True == 3. So people using booleans should not have too much difficulty, would they? Is there any chance you'd consider autoloading tinyint(1) as an integer field? sure i will remove this behavior today. it is out in r95ac46ca88ee. -- 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. -- 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.
