[sqlalchemy] String type with no length deprecation warnings in 0.4.2b
Hi,
I just upgraded to 0.4.2b (from 0.4.2) and now I get deprecation warnings
like this:
/usr/lib/python2.4/site-packages/sqlalchemy/databases/sqlite.py:389:
SADeprecationWarning: Using String type with no length for CREATE TABLE is
deprecated; use the Text type explicitly
colspec = self.preparer.format_column(column) + +
column.type.dialect_impl(self.dialect).get_col_spec()
I do understand why this warning is issued but I think there are two bugs left:
1. Even if I use the TEXT/Text type, the warning is issued (see example below):
users_table = Table('users', metadata,
Column('id', Integer, primary_key=True),
Column('name', sqlalchemy.types.Text)
)
2. Text is not exported in sqlalchemy/__init__.py, only TEXT is:
from sqlalchemy.types import \
BLOB, BOOLEAN, CHAR, CLOB, DATE, DATETIME, DECIMAL, FLOAT, INT, \
NCHAR, NUMERIC, SMALLINT, TEXT, TIME, TIMESTAMP, VARCHAR, \
Binary, Boolean, Date, DateTime, Float, Integer, Interval, Numeric, \
PickleType, SmallInteger, String, Time, Unicode
fs
--~--~-~--~~~---~--~~
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. the setuptools docs imply that anything alphabetically after final is a post release but I think we're going to have to go with 0.4.2r3, 0.4.2r4, etc. for the patch releases. --~--~-~--~~~---~--~~ 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: String type with no length deprecation warnings in 0.4.2b
On Jan 8, 2008, at 3:19 AM, Felix Schwarz wrote:
Hi,
I just upgraded to 0.4.2b (from 0.4.2) and now I get deprecation
warnings
like this:
/usr/lib/python2.4/site-packages/sqlalchemy/databases/sqlite.py:389:
SADeprecationWarning: Using String type with no length for CREATE
TABLE is
deprecated; use the Text type explicitly
colspec = self.preparer.format_column(column) + +
column.type.dialect_impl(self.dialect).get_col_spec()
I do understand why this warning is issued but I think there are two
bugs left:
1. Even if I use the TEXT/Text type, the warning is issued (see
example below):
users_table = Table('users', metadata,
Column('id', Integer, primary_key=True),
Column('name', sqlalchemy.types.Text)
)
2. Text is not exported in sqlalchemy/__init__.py, only TEXT is:
from sqlalchemy.types import \
BLOB, BOOLEAN, CHAR, CLOB, DATE, DATETIME, DECIMAL, FLOAT, INT, \
NCHAR, NUMERIC, SMALLINT, TEXT, TIME, TIMESTAMP, VARCHAR, \
Binary, Boolean, Date, DateTime, Float, Integer, Interval,
Numeric, \
PickleType, SmallInteger, String, Time, Unicode
can you try r4030 please
--~--~-~--~~~---~--~~
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 8, 2008, at 3:43 AM, Mike Orr wrote: Generally a third-level number is a minor bugfix release. A second-level number indicates feature changes or backward incompatibilities. A first-level number indicates a major paradigm shift. the problem with 0.4.3, 0.4.4 etc. is that we assign those numbers as milestones in trac, and we do have a notion of a set of features that will be slowly rolled out over the course of the 0.4 series. Its really just the 0. at the beginning of the number which makes our scheme different..so it would imply that we'd have a four-level version number, i.e. 0.4.2.1 0.4.2.2 etc. (because the 0. is pretty much superfluous). But we usually dont have fourth-level versions, its only because 0.4.2 got a little more involved than a usual point release that we are in this abc thing (which note at the moment ive switched to 0.4.2r3). as far as the 0., im really glad that the 0.1 series wasnt called SQLAlchemy 1.0 , as well as that 0.2 wasnt SQLAlchemy 2.0, etc. 0.1 and 0.2 were absolutely not major-version number products. 0.4 is starting to look more major versioned to me, but if we went thru 0.4 and then jumped to 1.0, that would seem kind of brittle as well. --~--~-~--~~~---~--~~ 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: Override default mapper behavior
On Jan 8, 2008, at 3:01 AM, Andrzej wrote: Hi, is this possible to override the behaviour of DELETE statement in ORM? I would like to update the table column instead of delete the row in case the object will be deleted (something like T.remove_date = timestamp). I know, there is a MapperExtension, but this - as I could see - allows me only to hook into 'before' and 'after' places within the process of deletion (Mapper._delete_obj) but does not prevent deletion of the row. I dont think that approach is advisable and you're probably better off not using session.delete() if you dont actually want something to be deleted- you should make your own delete() function which issues the timestamp change and whatever other dereferencing is needed (and no actual session.delete()) if thats what you want. For one thing, if you have an object A referenced by B as a parent, and a delete of B is superceded by an update of just a timestamp, now B still has the foreign key linking to A and will still show up as one of its children. If you want to try doing just what you describe, issue the UPDATE statement in the before_delete() mapper hook, and then remove the _instance_key attribute from the instance using del obj._instance_key; that should suppress the actual DELETE from occurring. but removing _instance_key as a way of doing this is not guaranteed to stay that way in future releases. --~--~-~--~~~---~--~~ 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: String type with no length deprecation warnings in 0.4.2b
Michael Bayer schrieb: can you try r4030 please Thank you very much, r4030 fixes the described problems. :-) fs --~--~-~--~~~---~--~~ 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] Issue with flush()
Hi,
Having just upgraded to the latest svn, I'm now getting the traceback below.
It looks like it's related to the attribute tracking changes. This is coming
from a fairly large program, but if it helps, I can extract a minimum test
case.
c:\sqlalchemy\lib\sqlalchemy\engine\base.py:1439: SADeprecationWarning:
Using String type with no length for CREATE TABL
E is deprecated; use the Text type explicitly
rec = (type_, type_.dialect_impl(self.dialect).result_processor(
self.dialect), i)
Traceback (most recent call last):
File C:\tsrweb\scripts\parse-results.py, line 20, in ?
turbogears.database.session.flush()
File c:\sqlalchemy\lib\sqlalchemy\orm\scoping.py, line 74, in do
return getattr(self.registry(), name)(*args, **kwargs)
File c:\sqlalchemy\lib\sqlalchemy\orm\session.py, line 693, in flush
self.uow.flush(self, objects)
File c:\sqlalchemy\lib\sqlalchemy\orm\unitofwork.py, line 215, in flush
flush_context.execute()
File c:\sqlalchemy\lib\sqlalchemy\orm\unitofwork.py, line 437, in
execute
UOWExecutor().execute(self, tasks)
File c:\sqlalchemy\lib\sqlalchemy\orm\unitofwork.py, line 927, in
execute
self.execute_save_steps(trans, task)
File c:\sqlalchemy\lib\sqlalchemy\orm\unitofwork.py, line 945, in
execute_save_steps
self.execute_dependencies(trans, task, False)
File c:\sqlalchemy\lib\sqlalchemy\orm\unitofwork.py, line 956, in
execute_dependencies
self.execute_dependency(trans, dep, False)
File c:\sqlalchemy\lib\sqlalchemy\orm\unitofwork.py, line 939, in
execute_dependency
dep.execute(trans, isdelete)
File c:\sqlalchemy\lib\sqlalchemy\orm\unitofwork.py, line 892, in
execute
self.processor.process_dependencies(self.targettask, [elem.state for
elem in self.targettask.polymorphic_tosave_elem
ents if elem.state is not None], trans, delete=False)
File c:\sqlalchemy\lib\sqlalchemy\orm\dependency.py, line 282, in
process_dependencies
self._process_key_switches(deplist, uowcommit)
File c:\sqlalchemy\lib\sqlalchemy\orm\dependency.py, line 285, in
_process_key_switches
switchers = util.Set(s for s in deplist if self._pks_changed(uowcommit,
s))
File c:\sqlalchemy\lib\sqlalchemy\orm\dependency.py, line 285, in
generator expression
switchers = util.Set(s for s in deplist if self._pks_changed(uowcommit,
s))
File c:\sqlalchemy\lib\sqlalchemy\orm\dependency.py, line 161, in
_pks_changed
return self.syncrules.source_changes(uowcommit, state)
File c:\sqlalchemy\lib\sqlalchemy\orm\sync.py, line 99, in
source_changes
if rule.source_changes(uowcommit, source):
File c:\sqlalchemy\lib\sqlalchemy\orm\sync.py, line 133, in
source_changes
prop = self.source_mapper._columntoproperty[self.source_column]
KeyError: Column('vulndescid', Integer(), ForeignKey('tsr.vulndesc.id'),
table=vulnmap)
Regards,
Paul
--~--~-~--~~~---~--~~
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 8, 2008 1:13 AM, Michael Bayer [EMAIL PROTECTED] wrote: the problem with 0.4.3, 0.4.4 etc. is that we assign those numbers as milestones in trac, and we do have a notion of a set of features that will be slowly rolled out over the course of the 0.4 series. [nod] That makes sense if you're assigning versions that way. Actually, it looks like Pylons is the same. I thought it was a three-level system but the current version is 0.9.6.1. as far as the 0., im really glad that the 0.1 series wasnt called SQLAlchemy 1.0 , as well as that 0.2 wasnt SQLAlchemy 2.0, etc. 0.1 and 0.2 were absolutely not major-version number products. 0.4 is starting to look more major versioned to me, but if we went thru 0.4 and then jumped to 1.0, that would seem kind of brittle as well. Well, 1.0 also implies a long-term commitment to the API, so you don't want to do it while you're still deciding what you want. I'm glad 0.3 wasn't called 1. 0.4 and its documentation are close to the quality of a 1.0 release. But you know better than I what SQLAlchemy 1.0 should contain. Do you have a specific set of features you want in it? Or are you just going to wait until the changes slow down and then make that version 1.0? -- 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: Override default mapper behavior
Thank you for a quick response. I'll try it and I'll risk the possible incompatibility with the future release for now... actual session.delete()) if thats what you want. For one thing, if you have an object A referenced by B as a parent, and a delete of B is superceded by an update of just a timestamp, now B still has the foreign key linking to A and will still show up as one of its children. I know that changing just a DELETE behaviour is not enough. Further I need to modify the SELECT behaviour in all possible places within ORM in order to eliminate all rows where 'remove_date is not null'. I've done this already in the methods .first, .one, .all and .count for know, placing there a hook from the MapperExtension (as a try-out) Could you give me a hint, what methods I need to 'hook' in order to change the way relations are populated? Then, although B has a foreign key to A, ORM would filter it out. I achieved such a functionality/transparency already with an Oracle database using VIEWS and INSTEAD_OF triggers. But placing this in ORM would make it DB-independent what I actually need, as I'm moving from Oracle to PostgreSQL. Thanks again, Andrzej --~--~-~--~~~---~--~~ 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: Override default mapper behavior
Thank you for a quick response. I'll try it and I'll risk the possible incompatibility with the future release for now... actual session.delete()) if thats what you want. For one thing, if you have an object A referenced by B as a parent, and a delete of B is superceded by an update of just a timestamp, now B still has the foreign key linking to A and will still show up as one of its children. I know that changing just a DELETE behaviour is not enough. Further I need to modify the SELECT behaviour in all possible places within ORM in order to eliminate all rows where 'remove_date is not null'. I've done this already in the methods .first, .one, .all and .count for know, placing there a hook from the MapperExtension (as a try-out) Could you give me a hint, what methods I need to 'hook' in order to change the way relations are populated? Than, olthough B has a foreign key to A, ORM would filter it out. I achieved such a functionality/transparency already with an Oracle database using VIEWS and INSTEAD_OF triggers. But placing this in ORM would make it DB-independent what I actually need, as I'm moving from Oracle to PostgreSQL. Thanks again, Andrzej --~--~-~--~~~---~--~~ 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: migrating to 0.4: Parent instance is not bound
Hello,
My migration to 0.4 didn't end well since now I sometimes get the following
error:
sqlalchemy.exceptions.InvalidRequestError: Parent instance class '
doupy.model.objects.JobPosting' is not bound to a Session, and no
contextual session is established; lazy load operation of attribute 'author'
cannot proceed.
My SA setup code looks like this:
# module globals
Session = scoped_session(sessionmaker(autoflush=True, transactional=False))
metadata_cache = {}
# this is called only once, when application starts
engine = engine_from_config(...)
Session.configure(bind=engine)
# when processing web requests
Session.query(..)
Max.
* *
--~--~-~--~~~---~--~~
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: Issue with flush()
On Jan 8, 2008, at 5:01 AM, Paul Johnston wrote: Hi, Having just upgraded to the latest svn, I'm now getting the traceback below. It looks like it's related to the attribute tracking changes. This is coming from a fairly large program, but if it helps, I can extract a minimum test case. test case would be necessary here, thanks ! --~--~-~--~~~---~--~~ 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: migrating to 0.4: Parent instance is not bound
Hi, sqlalchemy.exceptions.InvalidRequestError: Parent instance class ' doupy.model.objects.JobPosting' is not bound to a Session, and no contextual session is established; lazy load operation of attribute 'author' cannot proceed. Not 100% sure without seeing your model, but you probably want to use session.mapper in place of mapper. Paul --~--~-~--~~~---~--~~ 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, 2:50 am, jason kirtland [EMAIL PROTECTED] wrote: This was a bug in the reflection of empty string defaults. Give r4029 on the trunk a try. You're my hero -- for today, anyway. Thanks for the fast fix! --~--~-~--~~~---~--~~ 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] in operator and literal list
Hi All,
I'm wondering if there is a more elegant way to construct the
following piece of SQL:
SELECT * from MyTable where MyTable.MyColumn in ('foo', 'bar', 'baz');
The best I've come up with is the following:
ls = ['foo', 'bar', 'baz']
ls_str = str(ls).replace('[', '(').replace(']',')')
ls_str
('foo', 'bar', 'baz')
MyTable.filter(MyTable.c.MyColumn.op('in')(text(ls_str))
Which gives me the desired piece of SQL.
Ideally this would be expressed as:
MyTable.filter(MyTable.c.MyColumn.in(ls))
Cheers,
Eoghan
--~--~-~--~~~---~--~~
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: in operator and literal list
Eoghan Murray wrote: Ideally this would be expressed as: MyTable.filter(MyTable.c.MyColumn.in(ls)) Try: MyTable.filter(MyTable.c.MyColumn.in_(ls)) Just a guess. No time to see if this is right. --~--~-~--~~~---~--~~ 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] quick question...
I have been banging my head against the wall for a little bit attempting to translate this SQL: SELECT max(value) FROM ( SELECT max(sequence)+100 as value FROM task UNION SELECT 100.0 as value ) into an SQLAlchemy expression that I can embed into an INSERT. Should I just go ahead an use text() rather than bother with attempting to construct this using an SQLAlchemy expression? (Yes, I know that this is gross...) -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ 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: quick question...
and what this is expected to do? x = task and (max(task.sequence)+100) or 100 ? Jonathan LaCour wrote: I have been banging my head against the wall for a little bit attempting to translate this SQL: SELECT max(value) FROM ( SELECT max(sequence)+100 as value FROM task UNION SELECT 100.0 as value ) into an SQLAlchemy expression that I can embed into an INSERT. Should I just go ahead an use text() rather than bother with attempting to construct this using an SQLAlchemy expression? (Yes, I know that this is gross...) -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ 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: quick question...
unfortunately it requires a bugfix, r4031:
s = select([(func.max(task.c.sequence)
+100).label('value')]).union(select([literal(100.0).label('value')]))
print select([func.max(s.c.value)])
On Jan 8, 2008, at 4:37 PM, Jonathan LaCour wrote:
I have been banging my head against the wall for a little bit
attempting to translate this SQL:
SELECT max(value) FROM (
SELECT max(sequence)+100 as value FROM task
UNION
SELECT 100.0 as value
)
into an SQLAlchemy expression that I can embed into an INSERT.
Should I just go ahead an use text() rather than bother with
attempting to construct this using an SQLAlchemy expression?
(Yes, I know that this is gross...)
--
Jonathan LaCour
http://cleverdevil.org
--~--~-~--~~~---~--~~
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: quick question...
On Jan 8, 2008, at 5:05 PM, Jonathan LaCour wrote:
Michael Bayer wrote:
unfortunately it requires a bugfix, r4031:
s = select([(func.max(task.c.sequence)
+100).label('value')]).union(select([literal(100.0).label('value')]))
print select([func.max(s.c.value)])
Thanks Mike. My unit test now gets past the SQL generation, but
still fails. It appears that the SQL gets generated and run, but
the value doesn't show up in the database as expected.
Note: I am using this SQL expression as part of an insert by setting
it directly on my mapped object:
task = Task()
task.sequence = crazy sql expression
session.save(task)
Might this have something to do with it?
sure...what do your SQL logs say ?
--~--~-~--~~~---~--~~
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: quick question...
Michael Bayer wrote: sure...what do your SQL logs say ? 2008-01-08 17:41:21,832 INFO sqlalchemy.engine.base.Engine.0x..50 INSERT INTO task (sequence, subject, description, due_date, reminder, private, company_id, assigned_to_id, job_id) VALUES ((SELECT max(task.sequence) + ? AS value FROM task UNION SELECT ? AS value), ?, ?, ?, ?, ?, ?, ?, ?) 2008-01-08 17:41:21,833 INFO sqlalchemy.engine.base.Engine.0x..50 [100, '100.0', 'Item One', None, None, None, None, 1, None, None] -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ 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: quick question...
On Jan 8, 2008, at 5:42 PM, Jonathan LaCour wrote: Michael Bayer wrote: sure...what do your SQL logs say ? 2008-01-08 17:41:21,832 INFO sqlalchemy.engine.base.Engine.0x..50 INSERT INTO task (sequence, subject, description, due_date, reminder, private, company_id, assigned_to_id, job_id) VALUES ((SELECT max(task.sequence) + ? AS value FROM task UNION SELECT ? AS value), ?, ?, ?, ?, ?, ?, ?, ?) 2008-01-08 17:41:21,833 INFO sqlalchemy.engine.base.Engine.0x..50 [100, '100.0', 'Item One', None, None, None, None, 1, None, None] soits missing the outermost SELECT ? try an alias ? also, i think a CASE statement might be the better choice here to get the hardcoded 100 in there perhaps ? --~--~-~--~~~---~--~~ 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: in operator and literal list
On Jan 8, 2008, at 5:40 PM, Eoghan Murray wrote: On Jan 8, 7:28 pm, Jonathan Gardner [EMAIL PROTECTED] wrote: Eoghan Murray wrote: Ideally this would be expressed as: MyTable.filter(MyTable.c.MyColumn.in(ls)) Try: MyTable.filter(MyTable.c.MyColumn.in_(ls)) Just a guess. No time to see if this is right. That produces the following strange SQL where clause: WHERE MyTable.MyColumn = ARRAY['foo', 'bar', 'baz'] version 0.4 ? if on version 0.3 use in_(*list) --~--~-~--~~~---~--~~ 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: String type with no length deprecation warnings in 0.4.2b
I still get this on r4031 with MSSQL/pymssql. Are there changes that need to be made in the database module, maybe? Far as I can see all my Table() defs use the TEXT type identifier. On Jan 8, 2008 4:36 AM, Felix Schwarz [EMAIL PROTECTED] wrote: Michael Bayer schrieb: can you try r4030 please Thank you very much, r4030 fixes the described problems. :-) fs --~--~-~--~~~---~--~~ 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: String type with no length deprecation warnings in 0.4.2b
it has to do with what the string/text types in mssql.py inherit - if you inherit String you get the warning, if Text/TEXT, you dont. just look inside of dialect_impl(). On Jan 8, 2008, at 8:28 PM, Rick Morrison wrote: I still get this on r4031 with MSSQL/pymssql. Are there changes that need to be made in the database module, maybe? Far as I can see all my Table() defs use the TEXT type identifier. On Jan 8, 2008 4:36 AM, Felix Schwarz [EMAIL PROTECTED] wrote: Michael Bayer schrieb: can you try r4030 please Thank you very much, r4030 fixes the described problems. :-) fs --~--~-~--~~~---~--~~ 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: String type with no length deprecation warnings in 0.4.2b
I guess I'm being dense: I don't see it.
Here is what I think is doing the inheritence From mssql.py line 191-ish:
class MSText(*sqltypes.Text*):
def get_col_spec(self):
if self.dialect.text_as_varchar:
return VARCHAR(max)
else:
return TEXT
it currently uses no dialect_impl() override.
and then on line 366:
class MSSQLDialect(default.DefaultDialect):
colspecs = {
sqltypes.Unicode : MSNVarchar,
...
sqltypes.String : MSString,
*sqltypes.Text : MSText,
*...
}
On Jan 8, 2008 10:27 PM, Michael Bayer [EMAIL PROTECTED] wrote:
it has to do with what the string/text types in mssql.py inherit - if you
inherit String you get the warning, if Text/TEXT, you dont. just look
inside of dialect_impl().
On Jan 8, 2008, at 8:28 PM, Rick Morrison wrote:
I still get this on r4031 with MSSQL/pymssql. Are there changes that need
to be made in the database module, maybe? Far as I can see all my Table()
defs use the TEXT type identifier.
On Jan 8, 2008 4:36 AM, Felix Schwarz [EMAIL PROTECTED] wrote:
Michael Bayer schrieb:
can you try r4030 please
Thank you very much, r4030 fixes the described problems. :-)
fs
--~--~-~--~~~---~--~~
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: String type with no length deprecation warnings in 0.4.2b
its line 289 of compiler.py
def visit_typeclause(self, typeclause, **kwargs):
return typeclause.type.dialect_impl(self.dialect,
_for_ddl=True).get_col_spec()
if type subclasses Text, there should be no warning
On Jan 8, 2008, at 10:51 PM, Rick Morrison wrote:
I guess I'm being dense: I don't see it.
Here is what I think is doing the inheritence From mssql.py line 191-
ish:
class MSText(sqltypes.Text):
def get_col_spec(self):
if self.dialect.text_as_varchar:
return VARCHAR(max)
else:
return TEXT
it currently uses no dialect_impl() override.
and then on line 366:
class MSSQLDialect( default.DefaultDialect):
colspecs = {
sqltypes.Unicode : MSNVarchar,
...
sqltypes.String : MSString,
sqltypes.Text : MSText,
...
}
On Jan 8, 2008 10:27 PM, Michael Bayer [EMAIL PROTECTED]
wrote:
it has to do with what the string/text types in mssql.py inherit -
if you inherit String you get the warning, if Text/TEXT, you dont.
just look inside of dialect_impl().
On Jan 8, 2008, at 8:28 PM, Rick Morrison wrote:
I still get this on r4031 with MSSQL/pymssql. Are there changes
that need to be made in the database module, maybe? Far as I can
see all my Table() defs use the TEXT type identifier.
On Jan 8, 2008 4:36 AM, Felix Schwarz [EMAIL PROTECTED] wrote:
Michael Bayer schrieb:
can you try r4030 please
Thank you very much, r4030 fixes the described problems. :-)
fs
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
