Agreed, very funny comment Mike, and a good one:) Thanks.
On Sat, Jun 21, 2014 at 2:52 PM, Mike Bayer <mike...@zzzcomputing.com> wrote: > > 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 a topic in the > Google Groups "sqlalchemy" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/sqlalchemy/lT2VbGOACgY/unsubscribe. > To unsubscribe from this group and all its topics, 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. > -- 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.
