I cant keep up with all thats going on at this point, and the trunk
was just burstingso I need to get out what we have thus far and
see how far it flies.
Not very far around here, I'm afraid. Just updated and ran my test
suite (which passes with 0.3.3) and I'm getting batches of errors
see, i wish folks would use the trunk more. yeah, file tickets, and
every bug fixed becomes a unit test. this one seems like something
trivial. the inheritance thing, try to track that down...we have *so
many* inheritance tests at this point i cant believe theres still
basic issues
I filed #438 for the _data_appender thing:
http://www.sqlalchemy.org/trac/ticket/438.
For the other one, I'll try to put together a simple test case outside
of the code that belongs to my employer. I'll also see what I can do
about setting up a buildbot in our system to test our stuff against SA
I added some info from pdb and from the patch you attached to the
ticket. Both agree that for some reason, the attribute is a Query
instance instead of an InstrumentedList instance, which is more than a
little confusing. I'm trying to come up with a simplified test case,
but so far I haven't been
(repeating my last ticket comment)
Ok, I think I've tracked this down. The error is occurring because the
name of the backref is 'options', which as of r2205 is being
overwritten by assign_mapper.
I'm not sure what's the right thing to do here. I don't think
assign_mapper can avoid stepping on
hey jason -
someone reported an error regarding many-to-one relationships to
certain polymorphic joins, which was definitely introduced in 0.3.4.
ive fixed that issue in rev 2250. if your inheritance conditions use
polymorphic unions, you might want to try it out and see if it
resolves
ahha !
every time i let the little inoccuous ones go through this is what we
get.
this is actually somewhat of a legacy behavior, as the idea of saying
class Foo(object):someattribute=list was the old way to specify the
collection_class setting, and thats whats happening here; attribute
