On Jan 27, 2009, at 8:02 PM, Ross Vandegrift wrote:
> SA treats your model object (ie, the class that encapsulates the logic
> of your application) separately from the Session (ie, the class that
> encapsulates information on how to save and restore persistent data
> for object instances).
>
> I think of it like this: a Book object should keep properties about
> itself - the title, author, publication data, editon, etc. But a Book
> is not the kind of object that saves and loads things to a database.
> [1]
>
>
Well put, Russ. A Book() object represents ONE book, not a way to go
fetch books from somewhere else. Standard OO rules apply here: in
general, the methods attached to Book() should affect that books
attributes and only that books attributes.
And truth be told, it would really be a waste of your time trying to
make it do otherwise. SQLAlchemy has a wonderfully expressive query
language/API for you to use:
Your get_all() is just a one-liner:
model.meta.Session.query(Book).all()
Your get() method already exists as well:
model.meta.Session.query(Book).get(2543) <- primary key
Any other requirements are fullfilled by the filter/filter_by
functions Russ demonstrated.
When coding your to-be mapped classes, always code them (or at least
try damn hard) so that they could stand all alone without SQLAlchemy.
You should be able to instantiate them, change attribute values and
call all the methods of that object. It seems like 80%+ of the time,
I'm just writing Python properties in those classes to do data hiding/
manipulation anyway.
TJ
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
