[sqlalchemy] Re: in_ operator as kwarg to filter_by

[David S.]

 snip But now a user of the query
 needs to know about the underlying selectable itself

In case anyone reads this for info, that last statement is not true
because you can access the columns from the mapped class.  See
http://www.sqlalchemy.org/docs/datamapping.html#datamapping_query_columnsonclass.
In fact, you can even get at the mapped columns, and presumably
synonyms, via query_instance.mapper.c.

So if someone really did want to wrap a SA Query to look, act and walk
a little bit like Django's Model.objects (just to be constitent!) it
would be pretty straightforward.

Thanks, David S.


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

[sqlalchemy] in_ operator as kwarg to filter_by

[David S.]

I know that you can:
my_query.select_by(my_source.c.code.in_('1', '2'))

Is there a way to use kwargs with in_ as you can with equality
settings, as in:
my_query.select_by(code='1')

Since SA is NOT a framework, I imagine I could wrap the filter_by
method to work out Django style kwargs like code__in=(...), but if
there is an easier way...

Thanks,
David S.


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

[sqlalchemy] Re: in_ operator as kwarg to filter_by

[David S.]

 django's method of shoving SQL operators into the names of keyword
 arguments seems horribly ugly to me.   SQLAlchemy's approach is to
 use query.filter(sometable.c.col.in_(x, y)).   it uses the same
 operators as everything else without the need to memorize magic codes
 to embed in keyword names.   select_by() is deprecated in the
 upcoming 0.4 series.

I appreciate the appeal to aesthetics.  But now a user of the query
needs to know about the underlying selectable itself and not just the
field names.  It seems to lessens the utility of the filter_by
method.

Anyhow, thanks for the help.  SA is remarkable.

Peace,
David S.


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

[sqlalchemy] map from raw sql

[David S.]

I am working with a legacy db that falls short on such things as
having primary keys.  I have some sql that contrives to give me a
workable data set (with a columns that can serve as a composite
primary key).

I would like to just drop this in to a select() and generate a mapper
for it.  Is there a way to create a selectable without actually
defining any tables?  Thanks for any help.

Peace,
David S.


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