On Mon, Aug 27, 2012 at 4:57 PM, Michael Bayer <mike...@zzzcomputing.com>wrote:
>
> On Aug 27, 2012, at 4:43 PM, Jacob Biesinger wrote:
>
>
> Is the use case of having nested collections really all that out of
> mainstream?
>
>
> I would think just about any non-trivial application winds up having
> "nested collections". In relational databases this just means you have
> one-to-many relationships chained along. relationship() is the SQLAlchemy
> mechanism to achieve one-to-many. This is like the most prominent
> feature in the whole ORM so I'm not sure what's causing it to appear "non
> mainstream".
>
> If you're getting at the idea of having two or three big tables that
> generically handle all kinds of lists and dictionaries from all over the
> rest of the schema, yes, I'd characterize it as common, but not necessarily
> a best practice in most cases. It doesn't scale very well as those two or
> three giant tables grow to be huge, a single point of contention, hard to
> index and manipulate. Nevertheless we support this architecture through
> such notions as the "polymorphic association", which you'll find in the
> examples with the distribution.
>
Yes, this is the pattern I'm trying to describe though I've been thinking
of these as "typed collections", smallish tables for handling a particular
table's collections needs, which are all of a single type (so rows are
either a collection or a FK to ONE other table). It feels very doable,
given the many examples I've seen that don't go quite this far. If it's a
common enough use case, why not have an example on the best way to do this?
Thanks a ton for your quick responses. I'll try hacking something together
and will post here eventually.
>
> The real use case for the polymorphic association in the "single
> collection table" form is when you need to be able to find many types of
> parent objects together in one query against a selection of rows in the
> collection table. It usually requires using a UNION. This use case in
> my opinion is extremely rare, which is why in the polymorphic examples
> you'll find other recipes that encourage each parent class to have its own
> sub-table for its own collection of things of a certain type.
>
>
> It seems like a fairly straightforward requirement, though perhaps with a
> lot of boilerplate. A simple list-of-lists seems achievable using
> something like:
>
> all_lists = Table('all_lists', metadata,
> Column('id', Integer, primary_key=True),
> Column('type', String(32)), # polymorphic type... one
> of 'list' or 'scalar'
> Column('scalar_id', Integer, ForeignKey('scalars.id
> ')),
> Column('list_id', Integer, ForeignKey('all_lists.id
> ')))
>
> with an appropriate polymorphic identifier. Am I going down a dead-end
> here?
>
>
> --
> 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
> sqlalchemy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sqlalchemy?hl=en.
>
>
> --
> 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
> sqlalchemy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sqlalchemy?hl=en.
>
--
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
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
