On 6/21/14, 4:00 PM, Bao Niu wrote:
> The documentation regarding column_property and hybrid property says
> both methods are intended for linking a sql expression to an
> attribute, which is highly useful. But it is not obvious to junior
> users which one is preferred.
Heh. Well, one is much older than the other, and truthfully it is
also not obvious to *me* which one is preferred :). Hybrid property
is useful for more complex expressions where you'd like to have access
to an in-Python version when you already have an object loaded.
The way I used hybrids to a great extent, where i would not have used a
column_property(), was on an object that has dozens of methods used in a
complex report, and many of the methods built on each other (this is a
mock version of that):
class MyReportThing(Base):
# ...
@hybrid_property
def x(self):
# ...
@hybrid_property
def y(self):
# ...
@hybrid_property
def x_y_variance(self):
return variance(self.x, self.y, ...)
@hybrid_property
def average_foo_x(self):
# ..
# many more @hybrid_property objects
So when we'd generate a full report, we'd load all the MyReportThing
objects in fully. The table had perhaps 20 columns. But the report had
about 100. This is because from those 20 columns, the hybrids produced
80 other variants of the data within. This processing was much better
accomplished in Python than on the relational database side; we only
had to load 20 columns in and then use those 20 cols to generate many
other answers about that data. if it was all on the DB side there
would have been an enormous SQL statement with 100 columns.
But we still wanted to make these hybrids, because in some cases the
functions we had on MyReportThing were also useful in a query now and
then to use in query.filter(), like
query.filter(MyReportThing.average_foo_x > 25). In fact most of the
hybrids were part of an abstract interface that applied to many types of
objects, not just MyReportThing, and in this way the hybrids were very
flexible in-Python and sometimes in-SQL methods that didn't otherwise
have any complex interactions within the mapping process. Some
classes would override some of the hybrids to do something differently,
and some of them would even present "in-Python only" for some of them;
the @expression form would be overridden to raise a NotImplementedError
for some objects where calculating the values relied on things that
couldn't be acquired in a simple SQL expression.
I think for general use, business-level methods, hybrids are a lot more
flexible and work very well with heavily object oriented techniques.
The column_property() on the other hand is more about data that you'd
like to load every time on your object. When there's some view of data
that you really want at the SQL level, every time and up front when you
query(), column_property() can work better for that. But with
column_property() you really can't fall back onto any kind of
Python-side replacement of the feature. It's more rigidly tied to the
structure of how the database is queried.
column_property() is also used for rudimental mapping tasks, like if two
columns in a table or a JOIN should have the same value.
> I started by reading the ORM tutorial. The tutorial often references
> links to other pages, which makes it impossible for a newbie to learn
> something just by reading the tutorial itself.
well the tutorial is supposed to give you the general idea of how to
interact between a set of database tables and objects using SQLAlchemy.
However, it isn't by itself going to teach you much about object
oriented programming or about relational database programming
techniques. I'm not sure of your background, but if it is the case that
you're learning a little bit about all three at the same time, that is a
much harder hill to climb. I think this is somewhat the case for most
people that I interact with and is entirely normal - for example, I'm
now learning lots about Openstack, but as it turns out, in order to use
Openstack I really have to learn a whole lot more about networking as
well, and this is hard. But I can't blame Openstack's docs for the fact
that I'm not super clear on routers/subnetworks/etc. and all that,
there's multiple concepts to learn at once. I watch very closely what
people say about SQLAlchemy and at the same time I try to get indicators
for where they are coming from; the people that really love SQLAlchemy
the most are those who already have a database background and are also
not hostile to object oriented programming. The people who are the most
grumpy seem to be those who are learning database programming from the
ground up at the same time. The product by itself, and its
documentation, is only trying to solve the problem of integrating these
two worlds; it can't go too far as it stands into filling in details on
either side of that bridge except to the degree that the work people put
into it makes them more aware. I was assuming that there'd be a lot
more information surrounding SQLAlchemy by this time, that talks about
programming, relational databases, etc. with SQLAlchemy at the center,
but there's not nearly as much as I've hoped. To that end I've added
the videos and tutorials in the library section
http://www.sqlalchemy.org/library.html that I hope would give the
learner who has extra time to watch videos and stuff some more angles on
where things are coming from. It's been a many-year goal for there to
also be a book project that fills in more details regarding techniques.
> Sometimes I feel overwhelmed by the links to pages that is so
> technically detailed that after reading it I forgot where I left off
> in the tutorial.
this is a common problem when learning about something large....I will
try to keep the main document I'm reading open, then open up side links
in additional tabs so that my regular narrative remains open where I was
reading. Drilling down from general points into details and then out
again can be tedious but in computer programming overall it's ubiquitous.
> By the way, in my opinion a primer for newbie users on such advanced
> features is in high demand.
I'm not entirely sure about this, if one is a newbie, shouldn't they
stick with the basic patterns first, and only refer to advanced features
as their use cases find them there? Usually what I look for in a
product is that the new user can at least get up on the bike and pedal
forward. Jumping ramps and doing wheelies sorta comes later and more
slowly.... :)
--
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.
