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.
signature.asc
Description: Message signed with OpenPGP using GPGMail