On Nov 8, 2013, at 9:52 AM, JPLaverdure <jp.laverd...@gmail.com> wrote:

> Hi Michael,
> 
> Thanks for your response.
> 
> Is release 0.9 stable enough to use in a production env ?

it is for me, I’ve called it “beta” to give people a heads up but we’ve really 
gotten almost no regression/bug reports, so I’m likely to push it out as final 
very soon.   Though that’s when we *really* start getting the regression 
reports :) there are always some.

though this change is only to the versioning recipe, should work fine in 0.8, 
0.7 even, no need for 0.9 on this one.

> 
> When you mention that it isn't supported I'm a bit surprised/confused..

multi-level inheritance IMO is not that common.   we’re only talking about this 
versioning recipe here.  The ORM supports multi-level inheritance fully.

> 
> Anyhow,  I'll certainly give the latest version a spin but remain nervous of 
> the fact that it's still in beta. 

you can stick with 0.8 or whatever here, just make that change to the recipe.




> Will get back to you shortly.
> 
> JP
> 
> 
> On Thursday, November 7, 2013 8:36:53 PM UTC-5, Michael Bayer wrote:
> try out r29a07fc09a6c11b3e05457e2a from git master or rel_0_9, I have 
> multilevel joined inheritance working there now.
> 
> 
> On Nov 7, 2013, at 8:23 PM, Michael Bayer <mik...@zzzcomputing.com> wrote:
> 
>> I can’t even get multi-level inheritance to set up the mappers correctly, 
>> it’s not supported right now.   Would need some fixes.
>> 
>> 
>> 
>> 
>> On Nov 7, 2013, at 11:38 AM, JPLaverdure <jp.lav...@gmail.com> wrote:
>> 
>>> I seem to be having an issue when calling up the history of a versioned 
>>> SQLAlchemy class.
>>> I have the following inheritance structure setup:
>>> 
>>> Node(Versioned, Base)
>>> Specimen(Node)
>>> Animal(Specimen)
>>> 
>>> If I attempt to fetch the animal history using the query generated by :
>>> 
>>> AnimalHistory = self.__history_mapper__.class_
>>> q = object_session(self).query(AnimalHistory).filter(AnimalHistory.id == 
>>> self.id).order_by(AnimalHistory.version.desc())
>>>                             
>>> logger.debug(q)
>>> 
>>> I get the following query:
>>> 
>>> SELECT bla bla #trimmed for brevity
>>> FROM node_history
>>> JOIN specimen_history ON node_history.id = specimen_history.id AND 
>>> node_history.version = specimen_history.version
>>> JOIN animal_history ON specimen_history.id = animal_history.id
>>> WHERE animal_history.id = 28
>>> ORDER BY animal_history.version DESC
>>> 
>>> Basically, I seem to be missing the appropriate "AND" statement on the 
>>> animal_history JOIN.
>>> Because of this, I get an unwanted cartesian product between animal and 
>>> (specimen, node)
>>> 
>>> Could anyone point out the modification needed inside history_meta.py in 
>>> order to fix this ?
>>> 
>>> Thanks !!
>>> 
>>> -- 
>>> 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+...@googlegroups.com.
>>> To post to this group, send email to sqlal...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/sqlalchemy.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>> 
> 
> 
> -- 
> 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/groups/opt_out.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to