[sqlalchemy] Re: postgres table-name length?
Someone has recently made this claim without any supporting evidence, and I responded with an example of the compiler/ORM running against Oracle, truncating a long generated name, which had been aliased twice, into a properly truncated name, results returned just fine. This is a very actively developed feature of SQLA and it has a ton of unit tests. Without trac tickets there's no bugs as far as I know. It might be that this has been fixed in the latest version? The patches are against SQLAlchemy 0.4.5 btw. that just creates more work for us. Please make your patches against the latest version of the 0.4 maintenance branch checked out from SVN. This was the version that was current when our project begun, and which we have been working on. I will make an effort to port them to the latest version before posting them to trac. P.S. I could send you the patches privately if you want - I don't want to spam the whole list w 16kb of tgz that most people wouldn't care about... I would *greatly* appreciate if all discussion of SQLA implementation/ bugs be kept public, and bugs are dealt with in trac tickets, which accept patches as attachments. This is an open source project and when patches are made in secret and kept privately, you work against the entire thing. No worries - I did not intend to keep things /secret in any way/. Maybe I should not have offered the patches in that way in the PS. I nearly attached the whole tgz och patch-files to the mail to help the thread originator ASAP, and then realized that maybe that'd be rather impolite to most people on the list - most people might not be very interrested in the code, and might not want 16kb of junk in their inbox. So I removed it and added the PS. signature.asc Description: OpenPGP digital signature
[sqlalchemy] Re: postgres table-name length?
There are several bugs in how SA trunkates and mangles names for tables, indices, columns etc. With postgres it's not so bad, because the cutoff is at 64 chars (if you use elixir, set user_shortnames and you should be ok). It's much worse when using e.g. Oracle (with its 32 char limit and a heap of reserved words). I and a coworker (Axel Liljencrantz) has been working on a set of patches that fixes those issues once and for all, mainly to get Oracle to work, but they most of them are not oracle specific... I can't guarantee that we got everything right thou - we might have misunderstood how things where supposed to work... Does someone know where you are supposed to send patches/sets of patches for evaluation and possible inclusion in SA? The patches are against SQLAlchemy 0.4.5 btw. Best regards, Egil Möller P.S. I could send you the patches privately if you want - I don't want to spam the whole list w 16kb of tgz that most people wouldn't care about... [EMAIL PROTECTED] wrote: i hit some uncovered limitation, e.g. postgres truncating a name to 64 and then complaning about sqlalchemy.exceptions.ProgrammingError: (ProgrammingError) _Assoc_SluzhebnoNaznachenie__originalno_ANazn_sluzhebni_naznach is not a sequence 'select nextval(\'_Assoc_SluzhebnoNaznachenie__originalno_ANazn_sluzhebni_naznachenia_db_id_seq\')' (the last part enia_db_id_seq is missing any idea? i've renamed the tables alright, but this should be transparent somehow? maybe similar issue to ticket 820 'long index names' ? ciao svilen --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- signature.asc Description: OpenPGP digital signature
[sqlalchemy] Re: inverted in_
filter(sqlalchemy.not_(User.name.in_('alice', 'bob')))
How can I invert the in_ operator? I need a select like:
... name NOT IN ('alice', 'bob')...
...filter(not User.name.in_('alice', 'bob'))... is not working.
Hope that helps,
E
signature.asc
Description: OpenPGP digital signature
[sqlalchemy] Re: sqlite PK autoincrement not working when you do a composite PK?
YMMV. it is actualy you who break things. e.g. if u dont rely much on specific SQldialect notions, or better, on specific SQL notions, you'r settled. i've made dbcook over SA and ever since the team have forgotten about what SQL is, except some very tricky things which has to be SQL aware, as they rely on DB-structure being what it is. But dialects... only come to play when something is not supported, and my way of handling this so far is to avoid using any stuff that is not supported everywhere - workaround on lowe or higher level, including model refactoring I don't think that is a very workable strategy in the long run :( There are far to many bogus restrictions in some databases, e.g. Oracle, for any meaningful program to be written to work on all platforms w/o support/wrapping/hiding of ugly details by SA. I and a coworker are currently working on a patch-set to the oracle driver for SA for this very reason, fixing issues like: * broken mangling of forbidden/to long table/column names * missing support for the BOOL data type * missing support for boolean expressions in the column list ( select([tbl.c.col1 == tbl.c.col2]) ) (related to the last one above) You might think that you could easily get around the name-length barrier using the shortnames-option. But SA combines table names with column names to form aliases in select column lists, and the length quickly exceeds 32 characters (Oracles limit). In addition, do _you_ know which words are forbidden as column names in Oracle? I can assure you that there is at least a few you don't remember (and I wouldn't remember either :P)... Just a point of measurement (ok, oracle is the worst one...) Best regards, Egil signature.asc Description: OpenPGP digital signature
[sqlalchemy] Re: unexpected behaviour of in_
You seem to have stumbled into the same bug as I have while i fixed the IN SQL generation code for oracle to work inside the column list, not just in the where-clause. I ended up hacking SQLAlchemy/trunk/lib/sqlalchemy/sql/expression.py like this: 2166 https://projects.freecode.no/internal/projects/browser/div4/div4c/software/SQLAlchemy/trunk/lib/sqlalchemy/sql/expression.py#L2166 *class* _BinaryExpression(ColumnElement): ... 2181 https://projects.freecode.no/internal/projects/browser/div4/div4c/software/SQLAlchemy/trunk/lib/sqlalchemy/sql/expression.py#L2181 *def* *_get_from_objects*(self, **modifiers): 2182 https://projects.freecode.no/internal/projects/browser/div4/div4c/software/SQLAlchemy/trunk/lib/sqlalchemy/sql/expression.py#L2182 res = self.left._get_from_objects(**modifiers) 2183 https://projects.freecode.no/internal/projects/browser/div4/div4c/software/SQLAlchemy/trunk/lib/sqlalchemy/sql/expression.py#L2183 *if* self.operator *is* operators.in_op: *return* res 2184 https://projects.freecode.no/internal/projects/browser/div4/div4c/software/SQLAlchemy/trunk/lib/sqlalchemy/sql/expression.py#L2184 *return* res + self.right._get_from_objects(**modifiers) That seems to do the trick :) Best regards, Egil casbon wrote: Hi All, I am seeing something I didn't expect using in_. Here is a simple example, exactly as I expect: In [13]: col = Trade.c.TradeId.in_([1,2]) In [14]: sel = select([col]) In [15]: print col Trade.TradeId IN (?, ?) In [16]: print sel SELECT Trade.TradeId IN (?, ?) AS anon_1 FROM Trade But now, if I use a subselect, I see a problem: In [17]: col = Trade.c.TradeId.in_(select([Trade.c.TradeId])) In [18]: sel = select([col]) In [19]: print col Trade.TradeId IN (SELECT Trade.TradeId FROM Trade) In [20]: print sel SELECT Trade.TradeId IN (SELECT Trade.TradeId FROM Trade) AS anon_1 FROM Trade, (SELECT Trade.TradeId AS TradeId FROM Trade) The column definition (col) is as expected, but the select definition (sel) is strange. It selects two things and generates n^2 rows. How can I get the select I expect: SELECT Trade.TradeId IN (SELECT Trade.TradeId FROM Trade) AS anon_1 FROM Trade thanks, James --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- signature.asc Description: OpenPGP digital signature
