[sqlalchemy] Re: dynamic Tableclasses
On Wed, 02 Apr 2008 12:54:59 +0200 robert rottermann [EMAIL PROTECTED] wrote: def __init__(self, pid, **kw): self.ploneid = pid self.__dict__.update(kw) or do I fool the mapper (or anithing else) with noth explicitely assining values to all possible fields? The problem is in accessing __dict__ directly, that bypass all the attribute's getters and setters that SA plugs in on the mapped class. So you should do something like class MyClass(object): def __init__(self, pid, **kw): self.ploneid = pid for key in kw: setattr(self, key, kw[key]) instead. hth, ciao, lele. -- nickname: Lele Gaifax| Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas| comincerò ad aver paura di chi mi copia. [EMAIL PROTECTED] | -- Fortunato Depero, 1929. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Blasted ForeignKey exceptions
MySQL 5.0.38 with InnoDB tables / SQL Alchemy 0.4.4 / Python 2.5.1
Hi, I'm really impressed with SQL Alchemy in
general, but now that I'm trying to use it for a large-ish project,
I'm getting stuck more often than I'd like.
The problem is that when I try to create a record
that has foreign keys, I get: Exception: IntegrityError
'Cannot add or update a child row a foreign
key constraint fails. FOREIGN KEY(`tag`)
REFERENCES `tags`(`id`)
I _know_ that the tag with the particular ID is already
in the tags table.
The first time I had this problem, I had a one-to-
many between just two tables, and I would get this
error if I did a session.save(user) on the user side (
the one side) and then did a session.save(log_entry)
on the many side. I _really_ want to do the session
.saves like this sometimes. I got it to work by doing
the recommended user.logs.append(log_entry) with a
relation defined in the user mapper.
Now, I have a slightly more complex situation, and I
can't find a way to make it work. Every
time I try to tag the log entry, I get the
Integrity Errors.
My tables and mappings are:
self.user_table = Table('user', metadata,
Column('id', Integer, primary_key=True),
Column('username', Unicode(60), index=True),
Column('full_name', Unicode(80)),
Column('email', Unicode(80), index=True),
Column('pubkey', Unicode(120)),
Column('password_md5', Unicode(120)),
mysql_engine=innoDB
)
user_mapper = mapper(model.User, self.user_table,
properties = {
'logs': relation(model.Log, backref='author'),
'tags': relation(model.Tagging, backref='tagger'),
}
)
self.logtype_table = Table('log_type', metadata,
Column('id', Integer, primary_key=True),
Column('mime_type', Unicode(20)),
Column('is_python', Boolean),
mysql_engine=innoDB
)
mapper(model.LogType, self.logtype_table)
self.log_table = Table('log', metadata,
Column('id', Integer, primary_key=True),
Column('author_id', Integer, ForeignKey('user.id')),
Column('created', DateTime, nullable=False),
Column('type', Integer, ForeignKey('log_type.id')),
Column('title', Unicode(120), nullable=False),
Column('contents', UnicodeText, nullable=False),
Column('parent', Integer, ForeignKey('log.id')),
mysql_engine=innoDB
)
log_mapper = mapper(model.Log, self.log_table,
properties = { 'tags': relation(model.Tagging) }
)
self.tags_table = Table('tags', metadata,
Column('id', Integer, primary_key=True),
Column('name', Unicode(120), nullable=False),
mysql_engine=innoDB
)
mapper(model.Tag, self.tags_table)
self.taggings_table = Table('taggings', metadata,
Column('id', Integer, primary_key=True),
Column('tagger_id', Integer, ForeignKey('user.id'),
nullable=False),
Column('when', DateTime, nullable=False),
Column('tag', Integer, ForeignKey('tags.id')),
Column('tagged', Integer, ForeignKey('log.id')),
mysql_engine=innoDB
)
mapper(model.Tagging, self.taggings_table)
You can see that the last table has three Foreign Keys.
I can add a user (self.jim) to the database, and also a log
entry (self.log), and then I try to add a tag, and a tagging:
# add a user and a log entry
...
# add a tag
t = model.Tag('maplesong')
self.session.save(t)
self.session.flush() # successful
# and with that tag, we create a tagging
tg = model.Tagging(self.jim, self.log, t, datetime.today())
self.jim.tags.append(tg)
self.log.tags.append(tg)
self.session.flush() # Integrity Error
At which point I get the Exception: IntegrityError 'Cannot
add or update a child row a foreign key
constraint fails. FOREIGN KEY(`tag`) REFERENCES
`tags`(`id`)
I do not want to add the tagging to the tag... t.taggings.
add(tg) That doesn't make sense to me.
So my question is: How can I avoid these inappropriate
Integrity Errors? The foreign key that it's complaining
about really does already exist.
Thanks,
-Jim
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] ORM as a view
Hi, I use Alchemy to connection to a legacy system from which I pull data to be inserter into a new system that is being built with Python. I'm only interested by a tiny fraction of the legacy data and I'm wondering if it's possible to specify constraints to the mapper do that Obj.query() would only fetch rows with col_a == foo and col_b == bar. I know how to do that for a field of the object with relation(..., primary_join=...) How would I do that at the object level? -- Yannick Gingras --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] what = declarative_base
It makes me twitch when I see the following: Base = declarative_base(metadata=metadata) class Spam(Base): ... Base is a singularly undescriptive name to use for the base class of a declarative table class. People are doing this because it's in the documentation. If it were changed there, I think people would generally follow along. Would others be in favor of changing the documentation to something like this? Declarative = declarative_base(metadata=metadata) class Spam(Declarative): ... I'd be happy to implement the change throughout the declarative docs if there's support for the idea. Cheers, Cliff --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: what = declarative_base
On Apr 2, 2:41 pm, J. Cliff Dyer [EMAIL PROTECTED] wrote: It makes me twitch when I see the following: Base = declarative_base(metadata=metadata) class Spam(Base): ... Base is a singularly undescriptive name to use for the base class of a declarative table class. People are doing this because it's in the documentation. If it were changed there, I think people would generally follow along. Would others be in favor of changing the documentation to something like this? Declarative = declarative_base(metadata=metadata) class Spam(Declarative): ... I'd be happy to implement the change throughout the declarative docs if there's support for the idea. Its widely known that I defer all naming decisions to othersdo we like Declarative, or something more ActiveRecord-y ? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: what = declarative_base
I like having the base of my models be mypackage.model.Base . That name does a good job of describing what role the class plays; it is the common base on which each model is built. If I were mixing declarative and non-declarative models, then I could understand wanting the declarative ones to be distinguished as such, but as long as I have a common base for my models (which is also the case in the declarative documentation), I like it being called model.Base rather than being named after an implementation detail. Declarative is also longer and more annoying to type. On Wed, Apr 2, 2008 at 5:21 PM, Michael Bayer [EMAIL PROTECTED] wrote: On Apr 2, 2:41 pm, J. Cliff Dyer [EMAIL PROTECTED] wrote: It makes me twitch when I see the following: Base = declarative_base(metadata=metadata) class Spam(Base): ... Base is a singularly undescriptive name to use for the base class of a declarative table class. People are doing this because it's in the documentation. If it were changed there, I think people would generally follow along. Would others be in favor of changing the documentation to something like this? Declarative = declarative_base(metadata=metadata) class Spam(Declarative): ... I'd be happy to implement the change throughout the declarative docs if there's support for the idea. Its widely known that I defer all naming decisions to othersdo we like Declarative, or something more ActiveRecord-y ? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: mssql, Linux, unixODBC - Could not locate column in row for column
also of concern is that, nobodys ever going to know they need to use this parameter when this issue arises. Well the idea is that this is a workaround for what I suspect is a broken Unix + pyodbc configuration, not a long-term solution. its only because I narrowed the issue down to where I knew we needed those names to be that it was identified. hey not to be impolite, but I burned a little oil on this one too, ya know. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: mssql, Linux, unixODBC - Could not locate column in row for column
you can mix both freely. any class that has max_identifier_length on it, if you set self.max_identifier_length, that overrides it. Oh ok, nice. Alright, this is in trunk r4429 as a keyword parameter named max_identifier_length Lukasz: to use it, add the max_identifier_length as a keyword to create_engine() or as a db-uri keyword. Should be set to 30 for now. Rick On Wed, Apr 2, 2008 at 6:51 PM, Michael Bayer [EMAIL PROTECTED] wrote: On Apr 2, 2008, at 6:46 PM, Rick Morrison wrote: you're already hitting some limit of 30 for your cursor.description. This is a pyodbc debugging issue. A fix for now would be to change the max identifier length in MSSQL_pyodbc to 30 - perhaps we need to add this as a configurational option somehow for MS-SQL ? That would be a lot easier if the max_identifier_length was an instance attribute instead of a class attribute on the Dialect. Anybody using multiple connections is going to be hamstrung to the smaller limit. Any ideas around that? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: mssql, Linux, unixODBC - Could not locate column in row for column
On Wed, Apr 2, 2008 at 6:22 PM, Rick Morrison [EMAIL PROTECTED] wrote: also of concern is that, nobodys ever going to know they need to use this parameter when this issue arises. Well the idea is that this is a workaround for what I suspect is a broken Unix + pyodbc configuration, not a long-term solution. its only because I narrowed the issue down to where I knew we needed those names to be that it was identified. So how would I find out if this is pyodbc or unixodbc? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: mssql, Linux, unixODBC - Could not locate column in row for column
On Apr 2, 2008, at 7:06 PM, Rick Morrison wrote: you can mix both freely. any class that has max_identifier_length on it, if you set self.max_identifier_length, that overrides it. Oh ok, nice. Alright, this is in trunk r4429 as a keyword parameter named max_identifier_length Lukasz: to use it, add the max_identifier_length as a keyword to create_engine() or as a db-uri keyword. Should be set to 30 for now. also of concern is that, nobodys ever going to know they need to use this parameter when this issue arises. its only because I narrowed the issue down to where I knew we needed those names to be that it was identified. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: mssql, Linux, unixODBC - Could not locate column in row for column
So how would I find out if this is pyodbc or unixodbc? On Unix, it's both. pyodbc is the Python DB-API module that provides the DB-API2 interface for sqlalchemy it in turn relies on an underlying ODBC layer. unixodbc is the ODBC-for-Unix implementation that provides an ODBC interface (the ODBC layer) and manages various database drivers. There is an alternative to unixodbc called iodbc that does pretty much the same thing. Settings for things like identifier length, the appropriate driver to use, etc. are going to be in the domain of the ODBC implementation, e.g. unixodbc. You'll most likely find them in a file like /etc/odbc.conf , and documented in the unixodbc docs. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: mssql, Linux, unixODBC - Could not locate column in row for column
On Apr 2, 2008, at 7:22 PM, Rick Morrison wrote: hey not to be impolite, but I burned a little oil on this one too, ya know. absolutely ! oil burned all around. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: mssql, Linux, unixODBC - Could not locate column in row for column
On Wed, Apr 2, 2008 at 6:35 PM, Rick Morrison [EMAIL PROTECTED] wrote: So how would I find out if this is pyodbc or unixodbc? On Unix, it's both. pyodbc is the Python DB-API module that provides the DB-API2 interface for sqlalchemy it in turn relies on an underlying ODBC layer. unixodbc is the ODBC-for-Unix implementation that provides an ODBC interface (the ODBC layer) and manages various database drivers. There is an alternative to unixodbc called iodbc that does pretty much the same thing. Settings for things like identifier length, the appropriate driver to use, etc. are going to be in the domain of the ODBC implementation, e.g. unixodbc. You'll most likely find them in a file like /etc/odbc.conf , and documented in the unixodbc docs. Does the size of 30 apply to pyodbc on windows when connection to mssql? If not then its probably unixodbc, or vice versa. Lucas -- Automotive Recall Database. Cars, Trucks, etc. http://www.lucasmanual.com/recall/ Install Broadcom wireless card on Linux: http://lucasmanual.com/mywiki/bcm43xx --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
