[sqlalchemy] Lazier one-to-many relationships

I'm working on developing an API that, among other things, allows for partial updates or insertions to a parent's children. One minor problem that I've found is that any access to parent.children loads the entire collection -- when in many cases it's not necessary to do so. For instance,

[sqlalchemy] Lookup table referenced by multiple tables in parent query

I have a table structure something like this: * Two tables Foo and Bar * FooBar, an many-to-many association table between Foo and Bar * A County lookup table referenced by both Foo and Bar * A Region lookup table referenced by County I'm frequently running queries that involve both Foo and bar,

Re: [sqlalchemy] Mixing ORM and set-returning-functions (e.g. generate_series)

On Wednesday, November 13, 2013 4:48:47 PM UTC-8, Michael Bayer wrote: [...] see attached for demo, should get you started Thanks! That was a tremendous help. I've attached the version I ended up working with, using your code as a base. The main changes, besides some names, are: -

Re: [sqlalchemy] Mixing ORM and set-returning-functions (e.g. generate_series)

Gmail warns you before posting something with I've attached and no attachment, but apparently Google Groups does not. -- 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

Re: [sqlalchemy] Mixing ORM and set-returning-functions (e.g. generate_series)

I know it's been a few days, but I've finally had time to actually get back to this On Thursday, November 7, 2013 6:18:57 PM UTC-8, Michael Bayer wrote: On Nov 7, 2013, at 6:46 PM, Daniel Grace thisgen...@gmail.comjavascript: wrote: [...] that’s basically equivalent. If you want

[sqlalchemy] Mixing ORM and set-returning-functions (e.g. generate_series)

I've been using the ORM exclusively for my project and I've run into a particular case that has me stumped: I'm trying to find a way to generate SQL that essentially looks like this, using session.query() as a base: (Running on PostgreSQL) SELECT model.*, series.number FROM model,

Re: [sqlalchemy] Getting the unmodified version of an object without losing changes

The problem I was encountering is that history doesn't make it easy to differentiate between collections and non-collections very well: inspect(obj).attrs.intcolumn.history.unchanged returns return [intval], rather than intval. inspect(obj).attrs.children.history.unchanged returns [childobj]

[sqlalchemy] Getting the unmodified version of an object without losing changes

I have a situation where an object in the ORM performs some calculations and other assorted checks. One of these situations is checking to see the difference between the original value of an attribute and the current value -- in particular, some of the validation going on should prohibit a

[sqlalchemy] Having __mapper_args__ order by columns defined in a superclass?

I'm converting some existing code from reflecting tables in the database to actually defining all of the columns. One of my primary reasons for doing this is being able to apply mixins and such to table definitions -- for instance, there's numerous lookup tables which all have id and name

Re: [sqlalchemy] Having __mapper_args__ order by columns defined in a superclass?

On Monday, June 10, 2013 11:13:09 AM UTC-7, Michael Bayer wrote: [...] Using 0.8 you can pull the actual copied column name from the __table__: class SortedLookupTable(LookupTable): __abstract__ = True @declared_attr def __mapper_args__(cls): return {'order_by':

Re: [sqlalchemy] textcolumn.contains() escaping, the lack of icontains(), and possible bug?

Good to hear! I took a look at #2694 and it seems that using column.contains(other, autoescape=True) might get wordy fairly quick when -- at least in new applications -- it would be a handy default. While it's probably not particularly feasible, it'd be handy if the default for autoescape

[sqlalchemy] Avoid adding transient object to collection?

I need. -- Daniel Grace -- 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

[sqlalchemy] Default table aliasing (or: avoiding conflicts between foo.type_id and foo_type.id)

I ran into an issue today due to the following scenario: table foo (model class Foo) has a column type_id, which refers to the id column of table foo_type (model FooType) session.query(Foo, FooType), since the generated labels alias both foo.type_id and foo_type.id to foo_type_id, and thus the

[sqlalchemy] Re: Default table aliasing (or: avoiding conflicts between foo.type_id and foo_type.id)

I don't know how I managed to mangle that and thought I proofread my post, but that second bit should have read: session.query(Foo, FooType) doesn't work, since the label generation aliases both foo.type_id and foo_type.id to foo_type_id and thus causes an exception similar to : ... -- You

Re: [sqlalchemy] Explicit CROSS JOIN; or, left joining the cartesian product of two unrelated tables to a third

, April 5, 2013 10:07:55 AM UTC-7, Michael Bayer wrote: according to wikipedia, a CROSS JOIN is just a straight up cartesian product. So why not do a JOIN b on 1 == 1 ? query(model_a).join(model_b, literal(1) == 1).outerjoin(model_c, ...) On Apr 5, 2013, at 12:52 PM, Daniel Grace thisgen