On 12/10/2015 12:08 PM, Jonathan Vanasco wrote: > `sqlalchemy.func` does not map anything. It is a namespace for a > factory generator. anything you access with it becomes a function of > that caller's name. > > for example: > > filter( func.foo(table.column) > 1 ) > > produces > > WHERE foo(table.column) > 1 > > sqlalchemy generates the `foo` function dynamically though the `func` > namespace. > > In your example, `func.length` creates the sql "LENGTH()" not "LEN()". > It works because your backend supports "LENGTH" not "LEN". Most > databases use LENGTH (postgres, mysql, oracle, sqlite). Only MsSQL uses > LEN, and firebird has a completely different approach with CHAR_LENGTH, > BIT_LENGTH, etc. > > I don't think any more portability has ever been needed, because the > functions are either: > > * standardized across most databases due to common standards > * highly specfiic to a single database > > Trying to create a system that standardizes how every database handles > ancillary internal function "concepts" would be overwhelming and of > little real utility.
Well, I can see how it would be useful for general categories of functions - string functions, math functions, and especially date functions, which would be a huge job as all databases handle dates very differently. But at the very least it would probably less confusing if these "translated" functions were in a different namespace besides func., because, if some of the functions in func. translate and others don't, it's not consistent and the user has no idea what will happen. So first off, if we added that feature, people at this point wouldn't even know about it and it wouldn't get enough test coverage. Then secondly, it's of course a huge maintenance issue especially for date functions and such. Right now, when you really have a SQL function that you need to translate across backends, we supply the @compiles approach. See the examples at http://docs.sqlalchemy.org/en/rel_1_0/core/compiler.html#further-examples. > > If you really wanted to pursue this, I'd imagine you would work on the > SQL compliler or just inspect the db connection when you generate the > query and conditionally use different forms. > > -- > You received this message because you are subscribed to the Google > Groups "sqlalchemy" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to sqlalchemy+unsubscr...@googlegroups.com > <mailto:sqlalchemy+unsubscr...@googlegroups.com>. > To post to this group, send email to sqlalchemy@googlegroups.com > <mailto:sqlalchemy@googlegroups.com>. > Visit this group at http://groups.google.com/group/sqlalchemy. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
