[sqlalchemy] Re: Schema display
I tried to import boundMetadata and this has become MetaData, and I'm getting an import error ImportError: No module named sqlalchemy_schemadisplay So I was wondering if this has moved out of MetaData or been renamed. Morgan Michael Bayer wrote: where its always been... http://www.sqlalchemy.org/trac/wiki/UsageRecipes/SchemaDisplay On Jan 5, 2008, at 7:58 PM, [EMAIL PROTECTED] wrote: Hi Guys, I was wondering where the function create_schema_graph has gone, or what it has changed to. Any assistance would be appreciated. Let me know, Morgan --~--~-~--~~~---~--~~ 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: Schema display
sqlalchemy_schemadisplay.py is not part of the SQLAlchemy distribution - it's a separate script attached to that wiki page. You can download it from the link at the bottom of the page. Hope that helps, Simon -Original Message- From: sqlalchemy@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 07 January 2008 09:44 To: sqlalchemy@googlegroups.com Subject: [sqlalchemy] Re: Schema display I tried to import boundMetadata and this has become MetaData, and I'm getting an import error ImportError: No module named sqlalchemy_schemadisplay So I was wondering if this has moved out of MetaData or been renamed. Morgan Michael Bayer wrote: where its always been... http://www.sqlalchemy.org/trac/wiki/UsageRecipes/SchemaDisplay On Jan 5, 2008, at 7:58 PM, [EMAIL PROTECTED] wrote: Hi Guys, I was wondering where the function create_schema_graph has gone, or what it has changed to. Any assistance would be appreciated. Let me know, Morgan --~--~-~--~~~---~--~~ 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] SA 0.3.11 producing wrong code for func.any()
Hi, running SA 0.3.11 against PG 7.4. A SA query like session.query(Node).query(func.any(Node.c.tools=='1234') produces the following SQL code: select from node where where any(node.tools) = '1234'. However Postgres does not support this syntax and complains with a syntax error. Postgres requires: ...where '1234' = any(node.tools). Is there a workaround to get the syntax right through configuration? Andreas pgp38fYgWnK0u.pgp Description: PGP signature
[sqlalchemy] Re: broken relationship
I am not sure, but, I think after you save feed, in this case you don't need to call session.flush() maybe it is clearing the sessionand the feed object too. try to remove it or test if is none after session.flush() session.save (feed) session.flush () post= Post ( -- Alexandre da Silva Analista de Sistemas - Bacharel em Sistemas de Informação (2003-2007) gedit-todo http://alexandredasilva.wordpress.com/gedit-todo-list-plugin/ MicroDB http://www.assembla.com/space/microdb Open Sales Force System http://www.assembla.com/space/osfs opencomanche ([stopped] mail-me to get the latest source code) http://sourceforge.net/projects/opencomanche/ --~--~-~--~~~---~--~~ 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: broken relationship
On Mon, Jan 07, 2008 at 01:00:20AM -0200, Marcos Dione wrote: until yesterday did worked, but seems like after I upgraded to the new sqla 0.4.2-1 from Debian Sid, it broke this way. am I doing anything conceptually wrong? -- $ sqlite3 test.sqlt SQLite version 3.4.2 Enter .help for instructions sqlite select * from post; 1|http://bonga.org/posts/post.html||Fist post!|This the fist post. Like the fist import, but not.|2008-01-07 00:44:03|read ^^ this is where feed_id should not be NULL! sqlite select * from feed; 1|bonga|http://bonga.org/rss.xml|1 -- more info. this is with meta.echo= True: 2008-01-07 01:09:32,430 INFO sqlalchemy.engine.base.Engine.0x..14 BEGIN 2008-01-07 01:09:32,433 INFO sqlalchemy.engine.base.Engine.0x..14 INSERT INTO feed (name, url, active) VALUES (?, ?, ?) 2008-01-07 01:09:32,435 INFO sqlalchemy.engine.base.Engine.0x..14 ['bonga', 'http://bonga.org/rss.xml', 1] 2008-01-07 01:09:32,438 INFO sqlalchemy.engine.base.Engine.0x..14 COMMIT 2008-01-07 01:09:32,486 INFO sqlalchemy.engine.base.Engine.0x..14 BEGIN 2008-01-07 01:09:32,494 INFO sqlalchemy.engine.base.Engine.0x..14 INSERT INTO post (guid, feed_id, title, content, date, state) VALUES (?, ?, ?, ?, ?, ?) 2008-01-07 01:09:32,495 INFO sqlalchemy.engine.base.Engine.0x..14 ['http://bonga.org/posts/post.html', None, 'Fist post!', 'This the fist post. Like the fist import, but not.', '2008-01-07 01:09:32', 'read'] 2008-01-07 01:09:32,506 INFO sqlalchemy.engine.base.Engine.0x..14 COMMIT evidently sqla is not working for me as before. class SQLAObject (object): def __init__ (self, **kwargs): object.__init__ (self) self.__dict__.update (kwargs) I got this in IRC: 01:33 zzzeek_ styxman: updating __dict__ directly is a no no 01:33 zzzeek_ have to use setattr() maybe is that? I'll check later. -- (Not so) Random fortune: 10:22 el_machi e-squizo: es que ayer nos pasó lo impensable: estábamos por sopletear una pc para quitarle la tierra, en lo de un amigo, y en un descuido el perro nos meó la computadora... --~--~-~--~~~---~--~~ 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: sqlalchemy 0.4.2 released
Hey I've been busy and haven't had a chance to comment on the 0.4.2 release yet. Just wanted to give a big congrats on this release. I know it's one of the few releases out that have spawned an a (and looks like a forthcoming b) interim releases, but aside from those issues, it's a really nice release. Getting rid of lazy loads on backref operations was a huge win in my app: I saw speed-up times of upwards of 30% nearly across the board, with no regressions. The library continues to impress and I'm really glad to see this kind of development pace maintained even after years into the project. Makes me feel like I climbed on the right horse way back in the pre-0.1days. Thanks yet again to Mike and to the rest of the team! On 1/2/08, Michael Bayer [EMAIL PROTECTED] wrote: hey all and happy new year - I've just put out 0.4.2, a release that's a lot bigger than a point release would usually be. I've been kind of procrastinating with it, since we're in this phase where the source to SA is changing somewhat dramatically and a lot of old crufty things are being replaced with simpler ideas that do more and work better...while this was the main idea when we went from 0.3 to 0.4, it still continues. With this release we kept going and goingand there's still a bunch more things I want to do ! This release has a serious chunk of new features and other less noticeable things intended increase efficiency and/or improve behavior. Of the less noticeable things, the methodology used for attribute history tracking has changed from copy-on-load to copy-on- write (cuts down on ORM load times by about 25%), a new generic functions mechanism has been added which, while its only used a little bit so far, will eventually lead to better behavior of func.XXX constructs with regards to typing behavior and such, and the way mappers are linked to their classes has changed to be simpler and more efficient, as well as self-dereferencing. Another big one is that backref operations don't trigger lazy loads anymore; the changes to the reverse side of a relation are queued up if and when the reverse side actually loads. Still more, reconnect support was still a little flaky in 0.4.1 and has been fixed and unit tested like mad, adding the ability for a Connection to reconnect on its own; reconnect support was also added to Oracle. For the caching-enthused, you can pickle.dumps() any mapped instance, loads() it back, and all of its deferred/lazy/expired attribute loaders, even if they were set at the instance level via query.options() will remain intact; all the loaders are now serializable (plus unit tests galore). The unit of work's internals have been refactored significantly for clarity and decreased complexity. Big noticeable things include, mutable primary keys - change the primary key of an instance and flush(). There's some complexity to deal with if you have foreign keys referencing that PK, namely that you need to configure ON UPDATE cascades for a database that enforces FK integrity. For a non-FK enforcing database like sqlite or mysql MyISAM, you can set cascade_updates=True on relation() and SQLAlchemy will cascade the primary key change on its own, along mapped relationships. Another noticeable thing is that the Unicode type will issue a warning if you send a plain string to it; note that the Unicode type as well as flags like convert_unicode=True are meant to shuttle your Python unicode objects to the database using the db's native encoding; they are not intended to decode your application's raw Python bytestrings ! So now the assert_unicode flag, which is configurable as an error, warning (the default on Unicode), or neither (the default on String/engine), will let you know about that. synonym() has been totally overhauled to be way more usable. Check the docs on the site for this; you can now just set up your class- level property(), and just set up a synonym() on the mapper which will move the column out of the way for you in one step, and will also add the SQL-clause instrumentation to your property(), so saying MyClass.myprop == foo works just fine. Query.select_from() is a whole new animal now; you can literally put *any select statement* into it (now as a scalar argument), and continue to filter(), join(), and order_by(); all the criterion will be properly aliased against the selectable as though it were the mapped table. I wanted to go further with this, i.e. using the same methodology for polymorphic loads and also creating sub-queries of queries, but that stuff will be out in 0.4.3 and subsequent releases. Query has been refined in this release, particularly the instances() method (the main method that loads instances from a cursor), but still has some major things to be done (including fixing up count(), max(), min(), etc., yes I know these need work! - ticket 876). We also have a much easier-to-use TypeDecorator class;
[sqlalchemy] 0.4.2b likely today
hey list - another small bug with big side effects noted today, involving assignment of full collections (this is related to the overhaul of attribute history tracking in 0.4.2). If anyone is on 0.4.2 or 0.4.2a and having problems with flushes of collections, use svn r4023 or wait for 0.4.2b. - mike --~--~-~--~~~---~--~~ 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: broken relationship
On Mon, Jan 07, 2008 at 03:41:22PM -0200, Marcos Dione wrote: On Mon, Jan 07, 2008 at 01:00:20AM -0200, Marcos Dione wrote: class SQLAObject (object): def __init__ (self, **kwargs): object.__init__ (self) self.__dict__.update (kwargs) I got this in IRC: 01:33 zzzeek_ styxman: updating __dict__ directly is a no no 01:33 zzzeek_ have to use setattr() maybe is that? I'll check later. yes, it was. I changed the code to this and it started working again: class SQLAObject (object): def __init__ (self, **kwargs): object.__init__ (self) for (k, v) in kwargs.items (): setattr (self, k, v) -- (Not so) Random fortune: 23:19 perrito666 yogurt2ungue: justo estoy viendo una pelicula que demuestra en que se ha convertido #grulic 23:19 perrito666 alguna vez viste equilibrium? --~--~-~--~~~---~--~~ 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] SQLAlchemy 0.4.2b released
Hello again ! This is a bugfix release and is recommended for all users who are currently on 0.4.2 or 0.4.2a. There is one critical bugfix which involves history calculation on collection-based attributes. Other significant bugfixes include a potential error that can arise with delete-orphan cascade, a fix to synonym() regarding backrefs, some more advanced collections behavior fixes, a datetime-related fix to the MSSQL dialects, and a fix for the the order_by(None) call which can be used on a select() object in order to clear the criterion. Also, we just released two days ago and the changelog already has 11 new items. Geez ! download the latest and greatest at: http://www.sqlalchemy.org/download.html 0.4.2b -- - sql - changed name of TEXT to Text since its a generic type; TEXT name is deprecated until 0.5. The upgrading behavior of String to Text when no length is present is also deprecated until 0.5; will issue a warning when used for CREATE TABLE statements (String with no length for SQL expression purposes is still fine) [ticket:912] - generative select.order_by(None) / group_by(None) was not managing to reset order by/group by criterion, fixed [ticket:924] - orm - suppressing *all* errors in InstanceState.__cleanup() now. - fixed an attribute history bug whereby assigning a new collection to a collection-based attribute which already had pending changes would generate incorrect history [ticket:922] - fixed delete-orphan cascade bug whereby setting the same object twice to a scalar attribute could log it as an orphan [ticket:925] - Fixed cascades on a += assignment to a list-based relation. - synonyms can now be created against props that don't exist yet, which are later added via add_property(). This commonly includes backrefs. (i.e. you can make synonyms for backrefs without worrying about the order of operations) [ticket:919] - fixed bug which could occur with polymorphic union mapper which falls back to deferred loading of inheriting tables - the columns collection on a mapper/mapped class (i.e. 'c') is against the mapped table, not the select_table in the case of polymorphic union loading (this shouldn't be noticeable). - ext - '+', '*', '+=' and '*=' support for association proxied lists. - dialects - mssql - narrowed down the test for date/datetime in MSDate/ MSDateTime subclasses so that incoming datetime objects don't get mis-interpreted as date objects and vice versa, [ticket: 923] --~--~-~--~~~---~--~~ 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] Unicode data into Binary type
Database is mysql I am having a problem with unicode and binary type. I am using an XML parse the return Unicode strings. I have a table in mysql with the default character set as utf8 I set the charset to utf8 in the connect string to charset=utf8 I am trying to send a unicode string to the Binary column in the table and get the following traceback What does the python side need to be so that the Binary type case accept the data. The line that is failing in the Mysqldb: def Binary(x): return str(x) SQLAlchemny place: def bind_processor(self, dialect): DBAPIBinary = dialect.dbapi.Binary def process(value): if value is not None: return DBAPIBinary(value) else: return None return process File /usr/local/ltcd/lib/SQLAlchemy-0.4.1-py2.5.egg/sqlalchemy/engine/base.py, line 789, in execute return Connection.executors[c](self, object, multiparams, params) File /usr/local/ltcd/lib/SQLAlchemy-0.4.1-py2.5.egg/sqlalchemy/engine/base.py, line 840, in execute_clauseelement return self._execute_compiled(elem.compile(dialect=self.dialect, column_keys=keys, inline=len(params) 1), distilled_params=params) File /usr/local/ltcd/lib/SQLAlchemy-0.4.1-py2.5.egg/sqlalchemy/engine/base.py, line 849, in _execute_compiled context = self.__create_execution_context(compiled=compiled, parameters=distilled_params) File /usr/local/ltcd/lib/SQLAlchemy-0.4.1-py2.5.egg/sqlalchemy/engine/base.py, line 858, in __create_execution_context return self.engine.dialect.create_execution_context(connection=self, **kwargs) File /usr/local/ltcd/lib/SQLAlchemy-0.4.1-py2.5.egg/sqlalchemy/databases/mysql.py, line 1461, in create_execution_context return MySQLExecutionContext(self, connection, **kwargs) File /usr/local/ltcd/lib/SQLAlchemy-0.4.1-py2.5.egg/sqlalchemy/engine/default.py, line 174, in __init__ self.parameters = self.__convert_compiled_params(self.compiled_parameters) File /usr/local/ltcd/lib/SQLAlchemy-0.4.1-py2.5.egg/sqlalchemy/engine/default.py, line 228, in __convert_compiled_params param.append(processors[key](compiled_params[key])) File /usr/local/ltcd/lib/SQLAlchemy-0.4.1-py2.5.egg/sqlalchemy/types.py, line 440, in process return DBAPIBinary(value) File /var/lib/python-support/python2.5/MySQLdb/__init__.py, line 69, in Binary return str(x) UnicodeEncodeError: 'ascii' codec can't encode character u'\u201c' in position 37: ordinal not in range(128) --~--~-~--~~~---~--~~ 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: SQLAlchemy 0.4.2b released
On Jan 7, 2008 12:20 PM, Michael Bayer [EMAIL PROTECTED] wrote: This is a bugfix release and is recommended for all users who are currently on 0.4.2 or 0.4.2a. You really should bump the version number after a version has been released. 'a' and 'b' look like alpha and beta. I installed 0.4.2 this morning, and afterward easy_install -U SQLAlchemy says I already have the latest version. I had to install it specifically: easy_install SQLAlchemy==0.4.2b. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Unicode data into Binary type
Mike Bernson wrote: Database is mysql I am having a problem with unicode and binary type. I am using an XML parse the return Unicode strings. I have a table in mysql with the default character set as utf8 I set the charset to utf8 in the connect string to charset=utf8 I am trying to send a unicode string to the Binary column in the table and get the following traceback What does the python side need to be so that the Binary type case accept the data. [...snip...] UnicodeEncodeError: 'ascii' codec can't encode character u'\u201c' in position 37: ordinal not in range(128) The binary column types are expecting binary data- e.g. str instances, not unicode. The driver is trying to munge your unicode into bytes it can send over the wire and failing. So either encode/decode as utf8 in and out of the blob, or, better yet use a Unicode clob type instead and Unicode will go in and out automagically. --~--~-~--~~~---~--~~ 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: SQLAlchemy 0.4.2b released
On Jan 7, 2008, at 7:02 PM, Mike Orr wrote: On Jan 7, 2008 12:20 PM, Michael Bayer [EMAIL PROTECTED] wrote: This is a bugfix release and is recommended for all users who are currently on 0.4.2 or 0.4.2a. You really should bump the version number after a version has been released. 'a' and 'b' look like alpha and beta. I installed 0.4.2 this morning, and afterward easy_install -U SQLAlchemy says I already have the latest version. I had to install it specifically: easy_install SQLAlchemy==0.4.2b. that sort of sucks, i thought easy install could recognize lettered revsions. I cant see myself calling these 0.4.3 and 0.4.4 since a point release at that level for us usually means a lot more changes and time spent in SVN. i usually use alpha and beta to indicate such ive never thought of a and b that way. of course if we moved to whole numbers, that could help. --~--~-~--~~~---~--~~ 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: SQLAlchemy 0.4.2b released
Mike You just need pick letter that are after release. Thing like p1 is greater then release from the egg docs. (A note about versions: the egg runtime system understands typical version numbering schemes, so it knows that versions like 1.2a1 and 1.2rc5 are actually older than the plain version 1.2, but it also knows that versions like 1.2p1 or 1.2-1 are newer than 1.2.) Following a release number, you can have either a pre-release or post-release tag. Pre-release tags make a version be considered older than the version they are appended to. So, revision 2.4 is newer than revision 2.4c1, which in turn is newer than 2.4b1 or 2.4a1. Postrelease tags make a version be considered newer than the version they are appended to. So, revisions like 2.4-1 and 2.4pl3 are newer than 2.4, but are older than 2.4.1 (which has a higher release number). A pre-release tag is a series of letters that are alphabetically before final. Some examples of prerelease tags would include alpha, beta, a, c, dev, and so on. You do not have to place a dot before the prerelease tag if it's immediately after a number, but it's okay to do so if you prefer. Thus, 2.4c1 and 2.4.c1 both represent release candidate 1 of version 2.4, and are treated as identical by setuptools. Hope this helps. Michael Bayer wrote: On Jan 7, 2008, at 7:02 PM, Mike Orr wrote: On Jan 7, 2008 12:20 PM, Michael Bayer [EMAIL PROTECTED] wrote: This is a bugfix release and is recommended for all users who are currently on 0.4.2 or 0.4.2a. You really should bump the version number after a version has been released. 'a' and 'b' look like alpha and beta. I installed 0.4.2 this morning, and afterward easy_install -U SQLAlchemy says I already have the latest version. I had to install it specifically: easy_install SQLAlchemy==0.4.2b. that sort of sucks, i thought easy install could recognize lettered revsions. I cant see myself calling these 0.4.3 and 0.4.4 since a point release at that level for us usually means a lot more changes and time spent in SVN. i usually use alpha and beta to indicate such ive never thought of a and b that way. of course if we moved to whole numbers, that could help. --~--~-~--~~~---~--~~ 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: Schema display
Hi Guys, Maybe I'm missing something. I tried to import boundMetadata and this has become MetaData, and I'm getting an import error ImportError: No module named sqlalchemy_schemadisplay So I was wondering if this has moved out of MetaData or been renamed. Morgan Michael Bayer wrote: where its always been... http://www.sqlalchemy.org/trac/wiki/UsageRecipes/SchemaDisplay On Jan 5, 2008, at 7:58 PM, [EMAIL PROTECTED] wrote: Hi Guys, I was wondering where the function create_schema_graph has gone, or what it has changed to. Any assistance would be appreciated. Let me know, Morgan --~--~-~--~~~---~--~~ 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] problem autoloading PassiveDefaults under MySQL
I'm using mysql-5.1.15, sqlalchemy-0.4.2, mysql-python-1.2.2.
In SA-0.3, the docs read:
When Tables are reflected from the database using autoload=True, any
DEFAULT values set on the columns will be reflected in the Table
object as PassiveDefault instances.
This is not indicated behavior for 0.4. Is there any way to reproduce
this behavior short of manually transcribing each defaulting Column
into my Table definitions with PassiveDefault() as below?
Table('sometable', somemetadata,
Column('DefaultsToFoo', Unicode, PassiveDefault('Foo')),
autoload=True)
TIA,
--~--~-~--~~~---~--~~
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: problem autoloading PassiveDefaults under MySQL
On Jan 8, 12:25 am, Michael Bayer [EMAIL PROTECTED] wrote:
passivedefaults are reflected in 0.4 just as they are in 0.3, as much
as the underlying database allows them to be discovered.
Thanks for the quick reply. I reduced this to a small example and it
seems the failure I'm encountering is specifically with NOT NULL
columns that default to the empty string:
CREATE TABLE `monkey` (
`DefaultsToEmptyString` char(8) NOT NULL DEFAULT '',
`Id` int(11) NOT NULL,
PRIMARY KEY (`Id`)
) ENGINE=InnoDB;
#!/usr/bin/env python
from sqlalchemy import Table, MetaData, create_engine
from sqlalchemy.orm import mapper, sessionmaker
class Monkey(object):
pass
engine = create_engine('mysql:...')
SessionMaker = sessionmaker(bind=engine, autoflush=True,
transactional=True)
session = SessionMaker()
metadata = MetaData(bind=engine)
monkey = Table('monkey', metadata, autoload=True)
mapper(Monkey, monkey)
george = Monkey()
george.Id = 1
session.save(george)
session.commit()
...yields the exception:
sqlalchemy.exceptions.OperationalError: (OperationalError) (1048,
Column 'DefaultsToEmptyString' cannot be null) u'INSERT INTO monkey
(`DefaultsToEmptyString`, `Id`) VALUES (%s, %s)' [None, 1]
Again, if I add a PassiveDefault('') manually into a Table(), then
everything works fine under SA, which makes me think that SA is simply
not autoload'ing my DEFAULT '' for NOT NULL columns...
--~--~-~--~~~---~--~~
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: problem autoloading PassiveDefaults under MySQL
Smythe wrote:
On Jan 8, 12:25 am, Michael Bayer [EMAIL PROTECTED] wrote:
passivedefaults are reflected in 0.4 just as they are in 0.3, as much
as the underlying database allows them to be discovered.
Thanks for the quick reply. I reduced this to a small example and it
seems the failure I'm encountering is specifically with NOT NULL
columns that default to the empty string:
CREATE TABLE `monkey` (
`DefaultsToEmptyString` char(8) NOT NULL DEFAULT '',
`Id` int(11) NOT NULL,
PRIMARY KEY (`Id`)
) ENGINE=InnoDB;
[...snip...]
...yields the exception:
sqlalchemy.exceptions.OperationalError: (OperationalError) (1048,
Column 'DefaultsToEmptyString' cannot be null) u'INSERT INTO monkey
(`DefaultsToEmptyString`, `Id`) VALUES (%s, %s)' [None, 1]
Again, if I add a PassiveDefault('') manually into a Table(), then
everything works fine under SA, which makes me think that SA is simply
not autoload'ing my DEFAULT '' for NOT NULL columns...
This was a bug in the reflection of empty string defaults. Give r4029
on the trunk a try.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
