> 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 veeeeery 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
