Peter wrote: > Hi > > I discovered some differences in the results of the following simple > queries, when switching from a mysql to sqlite backend: > > > 1) for t in of_sqlalchemy.session.query(Transaction).all(): > > Works as expected with mysql (returns all rows ) , but fails to return > any data with sqlite. This could be fixed ( or perhaps: hacked ) with: > > for t in > of_sqlalchemy.session.query(Transaction).filter_by(desc='%').all():
no idea what that one is - check your SQL logs to examine the conversation > > 2) case sensitivity > > **supposing the dataset is effectively uppercase ( type == 'ROOT' ) > The following returns the dataset with uppcerase in mysql (which is > therefore case insensitive) , but not in sqlite ( the latter seems to > consider case ): > > accs = > of_sqlalchemy.session.query(Account).filter_by(type='root').all() > > Is this behavior due to sqlalchemy ? From what I found on typical > differences between mysql and sqlite, those above are not mentioned. different databases have different character collation behavior, with MySQL in particular being quite different from other DBs like sqlite and postgresql. SQLAlchemy at this time does not attempt to reconcile the wide range of collation variability on different backends, as the general subject of "collation" is only recently addressed by the SQL standard and has yet to see consistent adoption in backends. Theres a bit of discussion on this at http://www.sqlalchemy.org/trac/ticket/1003 and http://www.sqlalchemy.org/trac/ticket/487 . So for now you'd have to ensure case insensitive comparisons are filtered through func.lower(). -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
