Re: [Sqlalchemy-users] Re: Is there a count() method?

[Michael Bayer]

well heres that "humane interfaces" debate again.   Do you give the really smart set of constructs with which to build anything, or do you provide enormous "lists of functions" for every possible permutation of functionality some random application might want ?   Ive never liked anything in the latter category...its an instant indicator of the target audience for a particular tool or language.  they want to solve a small problem right now, they dont want to think about where their app is going, they couldnt care less about design patterns...they dont care what the bigger picture is, usually because theyve never been there.    That Fowler is chiming in for the "humane" side of things, well I think he just hes never been handed a big pile of Perl or PHP that needs some new functionality its designers never considered....that, or hes just courting the Ruby crowd since he likes to be where the action is. anyway, with SQLAlchemy I would like to keep the layers "broad", meaning that while its not going to try and predict every possible use via an encyclopedia of functions, its going to try to give you everything you need to stay within the particular layer of abstraction you are using it in (though always making it easy to drop down if needed).  So for "count" and other SQL functions, of which there are hundreds across the various databases, it gives you the "func" keyword which uses __getattr__ to let you specify as a Python _expression_ whatever function you want: mytable.select(mytable.c.col1 == func.substr(mytable.col2, "_lala")) today = select([func.sysdate()]).scalar() select([func.to_char(mytable.c.timestamp, "MM/DD/YYYY")], mytable.c.id==12) all that said, im not too opposed to adding "count" as a first class function off of selectables since its probably the most popular SQL function (im not into wholesale breaking of rules, but a slight bend here and there makes for a healthy balance) ...max, sum, substr, probably not.   On Dec 17, 2005, at 6:36 PM, Jonathan Ellis wrote: An API to all SQL features isn't something I want to see in an ORM.  I'd rather keep things simple and leave count, sum, etc. as functions you're welcome to drop down to a raw cursor to access. SQLAlchemy may well come the closest to "feature complete, but no more" of all the Python ORM projects.  The "Unit of work" concept and others show a level of sophistication not seen in the "I just want to use my database as an object store" tools.  Don't pollute it with a swiss army knife of seldom-used features. :) -- Jonathan Ellis http://spyced.blogspot.com