[sqlalchemy] need help for left join
Hello: I am new for SQLAlchemy and first time using with Plone. I need some help for left join. I have two tables, roles and roleElements. Structure and sample data for these two tables I am including for easy popup of table/data which will be useful to him\her who will try to help me. CREATE TABLE `roles` ( `roleId` int(10) unsigned NOT NULL auto_increment, `name` varchar(20) default NULL, `description` varchar(500) default NULL, `isActive` char(1) default NULL, `modifiedOn` datetime default NULL, `modifiedBy` int(10) unsigned default NULL, `createdOn` datetime default NULL, `createdBy` int(10) unsigned default NULL, PRIMARY KEY (`roleId`)) ENGINE=InnoDB DEFAULT CHARSET=latin1; - insert into `roles` (`roleId`,`name`,`description`,`isActive`,`modifiedOn`,`modifiedBy`,`createdOn`,`createdBy`) values (1,'Sys Admin','Sys Admin','Y','2007-06-01 13:42:15', 1,'2007-05-21 17:23:40',1); insert into `roles` (`roleId`,`name`,`description`,`isActive`,`modifiedOn`,`modifiedBy`,`createdOn`,`createdBy`) values (2,'President','Employee. Org Group. Owner of President Space and all sub spaces.','Y','2007-05-22 11:33:18',1,'2007-05-21 17:26:21', 1); insert into `roles` (`roleId`,`name`,`description`,`isActive`,`modifiedOn`,`modifiedBy`,`createdOn`,`createdBy`) values (3,'VP','Employee.\r\nOrg Group.\r\nOwner of VP Space all sub spaces.','Y','2007-05-22 11:33:36',1,'2007-05-21 17:27:39',1); insert into `roles` (`roleId`,`name`,`description`,`isActive`,`modifiedOn`,`modifiedBy`,`createdOn`,`createdBy`) values (4,'Division Head','Employee.\r\nOrg Group.\r\nOwner of Division Space all sub spaces.','Y',NULL,NULL,'2007-05-21 17:29:54', 1); insert into `roles` (`roleId`,`name`,`description`,`isActive`,`modifiedOn`,`modifiedBy`,`createdOn`,`createdBy`) values (5,'Department Head','Employee.\r\nOrg Group.\r\nOwner of Department Space all sub spaces.','Y',NULL,NULL,'2007-05-21 17:31:42',1); insert into `roles` (`roleId`,`name`,`description`,`isActive`,`modifiedOn`,`modifiedBy`,`createdOn`,`createdBy`) values (6,'Instructor','Employee.\r\nOrg Group.\r\nCRN Assigned.\r \nOwner of CRN Space all sub spaces.','Y',NULL,NULL,'2007-05-21 17:32:50',1); insert into `roles` (`roleId`,`name`,`description`,`isActive`,`modifiedOn`,`modifiedBy`,`createdOn`,`createdBy`) values (7,'Other Employee','Enployee.\r\nOrg Group.\r\nOwner of Projects/sub spaces.','Y',NULL,NULL,'2007-05-21 17:33:42',1); insert into `roles` (`roleId`,`name`,`description`,`isActive`,`modifiedOn`,`modifiedBy`,`createdOn`,`createdBy`) values (8,'Student','Student.\r\nOrg Group.\r\nOwner of Student Projects/sub spaces.','Y','2007-05-21 17:36:51',1,'2007-05-21 17:35:01',1); insert into `roles` (`roleId`,`name`,`description`,`isActive`,`modifiedOn`,`modifiedBy`,`createdOn`,`createdBy`) values (9,'Item Owner','Any User. Creator of file. Owns the file.','Y','2007-05-22 11:34:53',1,'2007-05-21 17:37:49',1); insert into `roles` (`roleId`,`name`,`description`,`isActive`,`modifiedOn`,`modifiedBy`,`createdOn`,`createdBy`) values (10,'Workspace Owner','Any user. \r\nOwner of Space its sub spaces.','Y','2007-05-22 11:39:43',1,'2007-05-21 17:38:36',1); insert into `roles` (`roleId`,`name`,`description`,`isActive`,`modifiedOn`,`modifiedBy`,`createdOn`,`createdBy`) values (11,'Contributor','Any User.\r\nContributor to the files.','Y','2007-05-22 11:40:22',1,'2007-05-21 17:40:32',1); insert into `roles` (`roleId`,`name`,`description`,`isActive`,`modifiedOn`,`modifiedBy`,`createdOn`,`createdBy`) values (12,'Approver','Any User.\r\nApproves/Rejects a file.','Y','2007-05-22 11:40:57',1,'2007-05-21 17:41:15',1); insert into `roles` (`roleId`,`name`,`description`,`isActive`,`modifiedOn`,`modifiedBy`,`createdOn`,`createdBy`) values (13,'Reviewer','Any user.\r\nReviews files enters comments.','Y','2007-05-22 11:41:25',1,'2007-05-21 17:42:19',1); insert into `roles` (`roleId`,`name`,`description`,`isActive`,`modifiedOn`,`modifiedBy`,`createdOn`,`createdBy`) values (15,'Test','Test','Y','2007-06-01 15:47:46',1,'2007-06-01 15:47:15',1); -- -- CREATE TABLE `roleElements` ( `roleElementId` int(10) unsigned NOT NULL auto_increment, `roleId` int(10) unsigned default NULL, `elementId` int(10) unsigned default NULL, `elementLevelId` int(10) unsigned default NULL, `isActive` char(1) default NULL, `modifiedOn` datetime default NULL, `modifiedBy` int(10) unsigned default NULL, `createdOn` datetime default NULL, `createdBy` int(10) unsigned default NULL, PRIMARY KEY (`roleElementId`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; - insert into `roleElements` (`roleElementId`,`roleId`,`elementId`,`elementLevelId`,`isActive`,`modifiedOn`,`modifiedBy`,`createdOn`,`createdBy`) values (1,2,1,1,'Y',NULL,NULL,'2007-05-24 15:45:25',1);
[sqlalchemy] Re: [PATCH] filter_by_via
IMHO, this solves my use case nicely. It's slightly longer than what I proposed but doesn't reach my internal this_is_too_long_to_type threshold and it's more explicit... So for me it's a +1 for that solution (along with documenting the joinpoint behavior ;-)). On 6/2/07, Michael Bayer [EMAIL PROTECTED] wrote: plus *another* option to think about here, which was actually my first (suppressed) instinct, but now i just saw that Hibernate sort of does this, is to *keep* the joinpoint in and just have the join function reset the joinpoint on each invocation. so, session.query(User).join(['orders', 'items']).filter_by (item_name='foo').join(['addresses']).filter_by (email_address='[EMAIL PROTECTED]').list() at the moment, this seems intuitive to me. but i dont know if itll stay that way. i do like that each method has a single type of argument, as opposed to filter_by(qualifier, **kwargs). -- Gaëtan de Menten http://openhex.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: [PATCH] filter_by_via
On 6/2/07, Gaetan de Menten [EMAIL PROTECTED] wrote: IMHO, this solves my use case nicely. It's slightly longer than what I proposed but doesn't reach my internal this_is_too_long_to_type threshold and it's more explicit... So for me it's a +1 for that solution (along with documenting the joinpoint behavior ;-)). Hmmm, after some more thoughts there is one little aspect of that which bothers me: once you joined to something, you can't add filtering criteria on the initial table/class. This is actually one of the features I disliked about the current code. It might be rare use case but I, for one, like to be able to construct queries in any order, so that I can factor out the common part and store it somewhere then add what is specific at a later point. Here, if the specific part is about the initial table, I'm screwed. Adding a method to just move/reset the joinpoint would solve this, though I find it ugly. Better than nothing though. This would look like this: q = session.query(User).join(['orders', 'items']).filter_by(item_name='foo'). user_query = q.join(['addresses']).filter_by(email_address='[EMAIL PROTECTED]').reset_joinpoint() users = user_query.filter_by(name='Foo').list() On 6/2/07, Michael Bayer [EMAIL PROTECTED] wrote: plus *another* option to think about here, which was actually my first (suppressed) instinct, but now i just saw that Hibernate sort of does this, is to *keep* the joinpoint in and just have the join function reset the joinpoint on each invocation. so, session.query(User).join(['orders', 'items']).filter_by (item_name='foo').join(['addresses']).filter_by (email_address='[EMAIL PROTECTED]').list() at the moment, this seems intuitive to me. but i dont know if itll stay that way. i do like that each method has a single type of argument, as opposed to filter_by(qualifier, **kwargs). -- Gaëtan de Menten http://openhex.org -- Gaëtan de Menten http://openhex.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] Anybody seen--Exception: invalid byte sequence for encoding UTF8?
Howdy All,
I've got some existing code that I'm trying on a new server. The code
was formerly running with Python 2.4 and SA 0.36, but this new server
is running Python 2.5 and SA 0.37.
Anyway, I've got a small program which is loading a PostgreSQL 8.2 db
from a CSV file, and I'm getting this exception:
sqlalchemy.exceptions.SQLError: (ProgrammingError) invalid byte
sequence for encoding UTF8: 0xe16e69
HINT: This error can also happen if the byte sequence does not match
the encoding expected by the server, which is controlled by
client_encoding.
The particular (fake, generated) set of data doing this is shown
here. It looks like that first element (city) is encoded as something
other than latin1:
{'city': 'Gu\xe1nica', 'first_name': 'Patricia', 'last_name':
'Wagner', 'zip': '25756', 'phone': '490.749.6157', 'state': 'KS',
'annual_salary': '72333', 'broker_id': 452L, 'date_hired':
datetime.date(2004, 1, 1), 'address': 'P.O. Box 815, 6723 Eget, Ave',
'commission_percentage': 0.080120064101811897}
Has anybody seen this? Do I need to do a convert_unicode or anything
like that?
Thanks,
Matt
--~--~-~--~~~---~--~~
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: [PATCH] filter_by_via
On Jun 2, 2007, at 6:02 AM, Gaetan de Menten wrote: Hmmm, after some more thoughts there is one little aspect of that which bothers me: once you joined to something, you can't add filtering criteria on the initial table/class. This is actually one of the features I disliked about the current code. It might be rare use case but I, for one, like to be able to construct queries in any order, so that I can factor out the common part and store it somewhere then add what is specific at a later point. Here, if the specific part is about the initial table, I'm screwed. Adding a method to just move/reset the joinpoint would solve this, though I find it ugly. Better than nothing though. This would look like this: q = session.query(User).join(['orders', 'items']).filter_by (item_name='foo'). user_query = q.join(['addresses']).filter_by (email_address='[EMAIL PROTECTED]').reset_joinpoint() users = user_query.filter_by(name='Foo').list() yeah i had that idea as well, and yeah its a little ugly. theres also the possiblity of using join(None). let me summarize things that im thinking we do: - we want to go with the joinpoint concept here, where join() starts from the beginning, and join(None)/reset_joinpoint brings it back. join() is used to add a join and also modify the joinpoint of the query, so that you can add more criterion using filter() or filter_by () or others. I think this particuar tweak would probably even be OK to put in the current trunk for release 0.3.8 unless people think its going to create problems...the only backwards-incompatible change being a join() starts from the beginning, not the previous join(). - i think filter_by(['list','of','properties'], **kwargs), i.e. an optional, positional string/list-of-strings argument, should also be present, and it will create the joins and criterion using table aliases, and will not be related to joinpoint at all. apparently django does this, and it would let us define criterion for multiple overlapping paths, such as q.filter_by(['a', 'b, 'c'], d=x).filter_by (['a', 'b', 'e'], d=x). thats something that you cant do with the straight join() alone (but of course you can do with explicit aliases and filter()/select_from()). - the auto find me a property behavior is gone. not sure if I want to remove it from select_by() and friends, i think it should probably remain in those in a deprecated state. - ClauseElement support would be removed from filter_by(). you can just use filter() for those. the older _by() methods, which i want to deprecate, would be left alone for backwards compatibility. - i want to deprecate all the criterion methods that are not filter, i.e. all the selects and most of the gets (except straight get()). selecting from a full statement we can do with query.from_statement (select statement), the argument of which is a select() or a string. deprecating select() and select_by() is to create a single simple interface to query based on the more flexible filter(). but it does mean a bit more typing in many cases. I would hope everyone is OK with 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: Anybody seen--Exception: invalid byte sequence for encoding UTF8?
On Jun 2, 2007, at 8:22 AM, Matt Culbreth wrote:
Howdy All,
I've got some existing code that I'm trying on a new server. The code
was formerly running with Python 2.4 and SA 0.36, but this new server
is running Python 2.5 and SA 0.37.
Anyway, I've got a small program which is loading a PostgreSQL 8.2 db
from a CSV file, and I'm getting this exception:
sqlalchemy.exceptions.SQLError: (ProgrammingError) invalid byte
sequence for encoding UTF8: 0xe16e69
HINT: This error can also happen if the byte sequence does not match
the encoding expected by the server, which is controlled by
client_encoding.
The particular (fake, generated) set of data doing this is shown
here. It looks like that first element (city) is encoded as something
other than latin1:
{'city': 'Gu\xe1nica', 'first_name': 'Patricia', 'last_name':
'Wagner', 'zip': '25756', 'phone': '490.749.6157', 'state': 'KS',
'annual_salary': '72333', 'broker_id': 452L, 'date_hired':
datetime.date(2004, 1, 1), 'address': 'P.O. Box 815, 6723 Eget, Ave',
'commission_percentage': 0.080120064101811897}
Has anybody seen this? Do I need to do a convert_unicode or anything
like that?
if youre parsing from the CSV file, your best bet is to parse the
data into python unicode objects using the expected encoding of the
filethat will detect any text in the file thats not in the
expected encoding. then just use the DB with convert_unicode=True
either on create_engine() or within the individual String() types
(String(convert_unicode=True) is now equivalent to Unicode()).
--~--~-~--~~~---~--~~
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: [PATCH] filter_by_via
what about adding a docopy=True (or dont_copy=False) to all methods that could be both copy_generative and modify-in-place? via some generic self=self.copy_if_required() func? Then one can choose at which point to split+copy let me summarize things that im thinking we do: - we want to go with the joinpoint concept here, where join() starts from the beginning, and join(None)/reset_joinpoint brings it back. join() is used to add a join and also modify the joinpoint of the query, so that you can add more criterion using filter() or filter_by () or others. I think this particuar tweak would probably even be OK to put in the current trunk for release 0.3.8 unless people think its going to create problems...the only backwards-incompatible change being a join() starts from the beginning, not the previous join(). - i think filter_by(['list','of','properties'], **kwargs), i.e. an optional, positional string/list-of-strings argument, should also be present, and it will create the joins and criterion using table aliases, and will not be related to joinpoint at all. apparently django does this, and it would let us define criterion for multiple overlapping paths, such as q.filter_by(['a', 'b, 'c'], d=x).filter_by (['a', 'b', 'e'], d=x). thats something that you cant do with the straight join() alone (but of course you can do with explicit aliases and filter()/select_from()). - the auto find me a property behavior is gone. not sure if I want to remove it from select_by() and friends, i think it should probably remain in those in a deprecated state. - ClauseElement support would be removed from filter_by(). you can just use filter() for those. the older _by() methods, which i want to deprecate, would be left alone for backwards compatibility. - i want to deprecate all the criterion methods that are not filter, i.e. all the selects and most of the gets (except straight get()). selecting from a full statement we can do with query.from_statement (select statement), the argument of which is a select() or a string. deprecating select() and select_by() is to create a single simple interface to query based on the more flexible filter(). but it does mean a bit more typing in many cases. I would hope everyone is OK with 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: Anybody seen--Exception: invalid byte sequence for encoding UTF8?
Thanks Michael, I'll do this.
When I change the model's column types to Unicode() I still get the
same type in the DB--character varying(100). I'm assuming that's
correct? The DB is using a UTF8 encoding.
On Jun 2, 9:53 am, Michael Bayer [EMAIL PROTECTED] wrote:
On Jun 2, 2007, at 8:22 AM, Matt Culbreth wrote:
Howdy All,
I've got some existing code that I'm trying on a new server. The code
was formerly running with Python 2.4 and SA 0.36, but this new server
is running Python 2.5 and SA 0.37.
Anyway, I've got a small program which is loading a PostgreSQL 8.2 db
from a CSV file, and I'm getting this exception:
sqlalchemy.exceptions.SQLError: (ProgrammingError) invalid byte
sequence for encoding UTF8: 0xe16e69
HINT: This error can also happen if the byte sequence does not match
the encoding expected by the server, which is controlled by
client_encoding.
The particular (fake, generated) set of data doing this is shown
here. It looks like that first element (city) is encoded as something
other than latin1:
{'city': 'Gu\xe1nica', 'first_name': 'Patricia', 'last_name':
'Wagner', 'zip': '25756', 'phone': '490.749.6157', 'state': 'KS',
'annual_salary': '72333', 'broker_id': 452L, 'date_hired':
datetime.date(2004, 1, 1), 'address': 'P.O. Box 815, 6723 Eget, Ave',
'commission_percentage': 0.080120064101811897}
Has anybody seen this? Do I need to do a convert_unicode or anything
like that?
if youre parsing from the CSV file, your best bet is to parse the
data into python unicode objects using the expected encoding of the
filethat will detect any text in the file thats not in the
expected encoding. then just use the DB with convert_unicode=True
either on create_engine() or within the individual String() types
(String(convert_unicode=True) is now equivalent to Unicode()).
--~--~-~--~~~---~--~~
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: Anybody seen--Exception: invalid byte sequence for encoding UTF8?
On Jun 2, 2007, at 10:58 AM, Matt Culbreth wrote: Thanks Michael, I'll do this. When I change the model's column types to Unicode() I still get the same type in the DB--character varying(100). I'm assuming that's correct? The DB is using a UTF8 encoding. yes convert_unicode means an incoming u'' object, on the bind parameter side, will be encoded to a utf8 string before its sent to the database...which is what your DB is expecting. --~--~-~--~~~---~--~~ 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: [PATCH] filter_by_via
what about adding a docopy=True (or dont_copy=False) to all methods that could be both copy_generative and modify-in-place? via some generic self=self.copy_if_required() func? Then one can choose at which point to split+copy well if you have switches that are dynamically modifying the central paradigm of the API, that suggests you arent too sure about that API. well... sooner or later u'll have mostly generative methods (which is, copying/cloning+extras), and then someone may need a faster modify-in-place version. say, by a special (metaclass or decorating) wrapper i could make a cloning version from any inplace one; but i cannot do it viceversa - if u make the cloning one the base. This wrapper/decorator can go in SA interfaces if u wish - where there is alternative. For some methods the cloning version will be official, for others - the inplace one. another way is the command pattern, cloning some very_cheap object, but i dont think it is very usable here. also that approach doesnt really solve this problem since the goal is to execute just one query with many features combined. it is not about solving some particular problem, it's just a generic way to modify/extend the API without really changing the look of it. so u dont end with manualy made filter_inplace() and filter_clone() one day.. Actualy inspired by the other thread about the inplace append_whereclause(). ciao svil --~--~-~--~~~---~--~~ 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: bug in OrderedDict?
sounds like a bug. add a ticket and/or create a patch ! thanks.
On Jun 2, 3:48 pm, Eric Ongerth [EMAIL PROTECTED] wrote:
I noticed that if you pop() an item out of an OrderedDict, then ask
the OrderedDict for its values(), you get a key error because the OD
doesn't trim its ._list when the pop() occurs.
Is this by design?
(demonstration below)
import sqlalchemy
from sqlalchemy.util import OrderedDict
od=OrderedDict()
od.update({'id':3L})
od.update({'mfr':'BD','model_name':'Stigma'})
od
{'mfr': 'BD', 'id': 3L, 'model_name': 'Stigma'}
od.values()
[3L, 'BD', 'Stigma']
od.pop('id')
3L
od
{'mfr': 'BD', 'model_name': 'Stigma'}
od._list
['id', 'mfr', 'model_name']
od.values()
Traceback (most recent call last):
File input, line 1, in module
File H:\Python25\lib\site-packages\sqlalchemy\lib\sqlalchemy
\util.py, line 243, in values
return [self[key] for key in self._list]
File H:\Python25\lib\site-packages\sqlalchemy\lib\sqlalchemy
\util.py, line 270, in __getitem__
return dict.__getitem__(self, key)
KeyError: 'id'
--~--~-~--~~~---~--~~
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.3.8 released
The 0.3 series is now coming in for a landing, foregoing shiny new
bells and whistles which are instead skipping ahead in the 0.4
branch. Release 0.3.8 is primarily a bugfix release, with some new
features of an only mildly spectacular nature (unless youre really
into every single MySQL datatype ever made...then its totally
spectacular). There is also a fairly spectacular speedup to
ResultProxy which removes a function call from every column fetch (of
course not as spectacular as the version in 0.4 which removes two or
three).
so heres the spectacular list of new whizbangs youll get by
downloading 0.3.8 at http://www.sqlalchemy.org/download.html :
0.3.8
- engines
- added detach() to Connection, allows underlying DBAPI connection
to be detached from its pool, closing on dereference/close()
instead of being reused by the pool.
- added invalidate() to Connection, immediately invalidates the
Connection and its underlying DBAPI connection.
- sql
- _Label class overrides compare_self to return its ultimate
object. meaning, if you say someexpr.label('foo') == 5, it
produces the correct someexpr == 5.
- _Label propigates _hide_froms() so that scalar selects
behave more properly with regards to FROM clause #574
- fix to long name generation when using oid_column as an order by
(oids used heavily in mapper queries)
- significant speed improvement to ResultProxy, pre-caches
TypeEngine dialect implementations and saves on function calls
per column
- parenthesis are applied to clauses via a new _Grouping
construct. uses operator precedence to more intelligently apply
parenthesis to clauses, provides cleaner nesting of clauses
(doesnt mutate clauses placed in other clauses, i.e. no 'parens'
flag)
- added 'modifier' keyword, works like func.foo except does not
add parenthesis. e.g. select([modifier.DISTINCT(...)]) etc.
- removed no group by's in a select thats part of a UNION
restriction [ticket:578]
- orm
- added reset_joinpoint() method to Query, moves the join point
back to the starting mapper. 0.4 will change the behavior of
join() to reset the join point in all cases so this is an
interim method. for forwards compatibility, ensure joins across
multiple relations are specified using a single join(), i.e.
join(['a', 'b', 'c']).
- fixed bug in query.instances() that wouldnt handle more than
on additional mapper or one additional column.
- delete-orphan no longer implies delete. ongoing effort to
separate the behavior of these two operations.
- many-to-many relationships properly set the type of bind params
for delete operations on the association table
- many-to-many relationships check that the number of rows deleted
from the association table by a delete operation matches the
expected results
- session.get() and session.load() propigate **kwargs through to
query
- fix to polymorphic query which allows the original
polymorphic_union to be embedded into a correlated subquery
[ticket:577]
- fix to select_by(propname=object instance) -style joins in
conjunction with many-to-many relationships, bug introduced in
r2556
- the primary_key argument to mapper() is propigated to the
polymorphic mapper. primary key columns in this list get
normalized to that of the mapper's local table.
- restored logging of lazy loading clause under
sa.orm.strategies logger, got removed in 0.3.7
- improved support for eagerloading of properties off of mappers
that are mapped to select() statements; i.e. eagerloader is
better at locating the correct selectable with which to attach
its LEFT OUTER JOIN.
- mysql
- Nearly all MySQL column types are now supported for declaration
and reflection. Added NCHAR, NVARCHAR, VARBINARY, TINYBLOB,
LONGBLOB, YEAR
- The sqltypes.Binary passthrough now always builds a BLOB,
avoiding problems with very old database versions
- support for column-level CHARACTER SET and COLLATE declarations,
as well as ASCII, UNICODE, NATIONAL and BINARY shorthand.
- firebird
- set max identifier length to 31
- supports_sane_rowcount() set to False due to ticket #370.
versioned_id_col feature wont work in FB.
- some execution fixes
-extensions
- new association proxy implementation, implementing complete
proxies to list, dict and set-based relation collections
- added orderinglist, a custom list class that synchronizes an
object attribute with that object's position in the list
- small fix to SelectResultsExt to not bypass itself during
select().
- added filter(), filter_by() to assignmapper
--~--~-~--~~~---~--~~
You
[sqlalchemy] Re: Bug in .query()[11:22]
On Jun 1, 11:57 pm, Mike Orr [EMAIL PROTECTED] wrote: My point is, if the second number is lower than the first, shouldn't SQLAlchemy transform it into a query that returns no records? I.e., LIMIT 0, which MySQL at least allows. Because that's what the Python equivalent would do: range()[1420:20] [] this is like the argument with the empty in_() clause. i like to err on the side of no silent failures / assumptions. but i lost the argument with the in_() clause, so im willing to lose the argument here. even though i really think python should be raising an error here too...why doesnt it ? --~--~-~--~~~---~--~~ 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: Bug in .query()[11:22]
On 6/2/07, Michael Bayer [EMAIL PROTECTED] wrote: On Jun 1, 11:57 pm, Mike Orr [EMAIL PROTECTED] wrote: My point is, if the second number is lower than the first, shouldn't SQLAlchemy transform it into a query that returns no records? I.e., LIMIT 0, which MySQL at least allows. Because that's what the Python equivalent would do: range()[1420:20] [] this is like the argument with the empty in_() clause. i like to err on the side of no silent failures / assumptions. but i lost the argument with the in_() clause, so im willing to lose the argument here. even though i really think python should be raising an error here too...why doesnt it ? Because iterating when you're already past the end of something produces an empty result throughout Python. range(10, 7) [] range(10, 7, -1) [10, 9, 8] it = iter([1, 2, 3]) it.next() 1 it.next() 2 it.next() 3 for i in it: ... print Found, i ... The last 'for' loop could raise an error, but it doesn't in Python or other languages, it just doesn't loop at all. -- 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: bug in OrderedDict?
done and done: Ticket #585.
Patch reprinted here for the curious passerby:
def pop(self, key=None):
if key == None:
try:
key = self._list[0]
except IndexError:
raise IndexError('tried to pop() from an empty
OrderedDict')
result = self[key]
dict.__delitem__(self, key)
self._list = self._list[1:]
return result
elif not key in self:
raise KeyError(key)
else:
self._list.remove(key)
return dict.pop(self, key)
On Jun 2, 2:30 pm, Michael Bayer [EMAIL PROTECTED] wrote:
sounds like a bug. add a ticket and/or create a patch ! thanks.
On Jun 2, 3:48 pm, Eric Ongerth [EMAIL PROTECTED] wrote:
I noticed that if you pop() an item out of an OrderedDict, then ask
the OrderedDict for its values(), you get a key error because the OD
doesn't trim its ._list when the pop() occurs.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
