There's nothing wrong with putting complex queries in your model
layer. It's a good thing IMO.
One technique I like to use with SQLAlchemy is subclassing the query
object. This becomes rather useful when you find yourself combining
the same common set of criterion in different ways depending on the
context, but it can be useful for abstracting more complex logic as
well. A trivial example:
class ThingQuery(orm.Query):
def published(self):
return self.filter(Thing.is_published == True)
def with_xyz(self):
return self.options(eagerload(xyz))
class Thing(Base):
query = DBSession.query_property(ThingQuery)
published_things = Thing.query.published().with_xyz()[:10]
num_things = Thing.query.published().count()
For my own use I find it helpful to have the Query subclass for
operations that involve a set of rows, and then methods on the mapped
class itself are for dealing only with one specific row at a time.
As Mariano was saying, it might be possible save yourself some trouble
by using mappers directly instead of DeclarativeBase. You'd likely be
able to make your python objects easier to work with because they
won't be tied 1-to-1 to the schema that you're building on. This isn't
about defining relations so much as composing your mapped classes into
their most logical form. A single mapped class can span multiple
tables or do practically whatever else you want. YMMV but it's worth a
look.
Nathan
On 2011 Jan 20, at 3:45 PM, Juliusz Gonera wrote:
Mariano Mara wrote:
Looks to me you should be building all those relations at mapper
level
[1][2]. You can map with other classes and even arbitrary sql
statements,
plus you can make some of them lazy loaded so that you won't have to
retrieve them until the very last minute.
Of course all of this will be defined in your model, making your
controller lighter.
I know all of that (you can see a relationship and append() in my
simple example). That's not what I'm asking. I'm making an app for a
database that I didn't design myself. It has some weird assumptions
and I use reflection (with declarative base).
The database is quite complex and simply defining relations is not
enough. I have to create a lot of objects which all are related to
one, let's call it, master object in a single controller action, on
single request (after parsing a very long form). Additionaly, I have
to make some checks in the database (query it to e.g. see if
something already exists) during the whole action. That's why I
asked if I it's OK (good practice) to make DB queries inside model's
method.
The action is 100 lines, I think it's too much for a single
function. Question: What are the recommended ways of decomposing
such actions in Pylons (or MVC frameworks in general).
--
Juliusz Gonera
http://juliuszgonera.com/
--
You received this message because you are subscribed to the Google
Groups "pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com
.
For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en
.
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
