[sqlalchemy] Versioning and multi-level inheritance

Hello, I'm trying to use the versioning recipe describe on the website along with a multi-level inheritance model (Joined-Table inheritance) Here are my declarative statements: [code] class Sample(Base): __metaclass__ = VersionedMeta __tablename__ = 'sample' __table_args__ =

[sqlalchemy] Querying specific class using String name of class

Hello, Is there a proper way to retrieve a class using its name other than going through the _decl_class_registry dictionary of declarative_base ? I'm using the Joined Table Inheritance and would like to enable users to query specific subtypes. ie: if I have the following structure: Base =

[sqlalchemy] Re: Querying specific class using String name of class

Hi Mike, Thanks for the reply. I'm just not sure that using `eval` represents a cleaner way than my original code... The Class query options are specified by the end user through a select (html form) so using eval poses a security risk I would like to avoid. I was hoping slqalchemy would

Re: [sqlalchemy] Re: Versioning and multi-level inheritance

Hi Michael, Thank you for your reply. Unfortunately, the mistake was all mine... At some point (and for an obscure reason...), I had stopped using the VersionedListener so changes were no longer registering in the DB :-/ So sorry ! JP -- You received this message because you are subscribed

[sqlalchemy] Versioning and Foreign Keys

Hello, I'm using the versioned objects suggested in the SQLAlchemy examples: http://www.sqlalchemy.org/docs/orm/examples.html#versioned-objects One of the aspects of entity management seems a bit weird though: If entities are linked using foreign keys, (let's say in one-to-many relationship),

[sqlalchemy] Re: Versioning and Foreign Keys

Oops, above references to versioned_meta should read history_meta. Sorry -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To view this discussion on the web visit https://groups.google.com/d/msg/sqlalchemy/-/0ZtFX94qz_wJ. To post to this group,

Re: [sqlalchemy] Versioning and Foreign Keys

Hi Michael, Thanks for your reply... Your input is always very resourcefull, thanks ! I put together a small example which doesn't seem to function as expected: class Sample(Base): __metaclass__ = VersionedMeta __tablename__ = 'sample' __table_args__ = {'schema':'test'} id =

Re: [sqlalchemy] Versioning and Foreign Keys

Oh god... I thought the statements used when declaring the ForeignKey (ondelete, onupdate) would imply that the relationship function in the same manner. I didn't think the 2 would be decoupled so much.. Although now that you point it out, it does seem consistent. I guess when I thought the

[sqlalchemy] ConcreteBase (0.7.3) only supporting 1 level of inheritance ?

Hello, I started playing with Concrete Table Inheritance this morning and tried to implement a portion of my schema: class Mixin(object): __table_args__ = {'schema':'test'} id = Column(Integer, primary_key=True) class Node(ConcreteBase, Base, Mixin): __tablename__ = 'node'

Re: [sqlalchemy] ConcreteBase (0.7.3) only supporting 1 level of inheritance ?

Hello Michael, Sorry to be the thorn in your side.. I attached a test case as requested.. Ticket 2312. Also, it seems this is incompatible with history_meta based versioning. (Which probably has to do with the use of the __declare_last__() function. Thank you -- You received this message

[sqlalchemy] Multi-Level inheritance and history_meta versioning issue

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 =

Re: [sqlalchemy] Multi-Level inheritance and history_meta versioning issue

, 2013, at 8:23 PM, Michael Bayer mik...@zzzcomputing.comjavascript: 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.comjavascript: wrote: I

Re: [sqlalchemy] Multi-Level inheritance and history_meta versioning issue

the presence of schemas (I mainly work on postgresql). Maybe those could be included in the main distro ? I'll submit a pull request with those changes in case you deem them interesting. Cheers ! JP On Friday, November 8, 2013 9:52:13 AM UTC-5, JPLaverdure wrote: Hi Michael, Thanks for your

Re: [sqlalchemy] SAWarnings when using history_meta.py versioning and Inheritance.

to remove the changed attribute... Well, I'm the one who suggested its addition and submitted the pull request :) Thanks, JP On Friday, 17 October 2014 16:05:15 UTC-4, Michael Bayer wrote: On Oct 17, 2014, at 3:50 PM, JPLaverdure jp.lav...@gmail.com javascript: wrote: Hi Michael, My

Re: [sqlalchemy] SAWarnings when using history_meta.py versioning and Inheritance.

: “version” is part of the primary key and is FK’ed to the superclass table, so the warning isn’t generated for that one. it wouldn’t be appropriate for a datetime “changed” to have a foreign key. IMO it only needs to be on the base table. On Oct 21, 2014, at 2:35 PM, JPLaverdure jp.lav

Re: [sqlalchemy] Injecting User info into _history table to track who performed the change

24:03 a.m. UTC-4 Simon King wrote: > Can you show us the mapping definitions that are triggering these warnings? > > On Mon, Mar 22, 2021 at 6:29 PM JPLaverdure wrote: > > > > Hi, > > > > Thanks for your support guys. > > > > I've implemente

Re: [sqlalchemy] Injecting User info into _history table to track who performed the change

as a "user" column, and you're trying to add > a second "user" column in the process_history table, which can't work. > > If you use a different column name to store the user in the history > table, does the warning go away? > > Simon > > On Tue, Mar 2

Re: [sqlalchemy] Injecting User info into _history table to track who performed the change

t; the local (inheriting) table as well as whatever columns the parent > class was targeting. > > You should test that when you modify a CompoundAdministration object, > you get a new row in both the compound_administration_history and the > process_history tables, and that the "acco

Re: [sqlalchemy] Injecting User info into _history table to track who performed the change

explicitly. Thanks for your help resolving this, JP On Tuesday, March 23, 2021 at 6:24:03 a.m. UTC-4 Simon King wrote: > Can you show us the mapping definitions that are triggering these warnings? > > On Mon, Mar 22, 2021 at 6:29 PM JPLaverdure wrote: > > > > Hi, > > >

[sqlalchemy] Injecting User info into _history table to track who performed the change

Hello everyone, We already have the ability to timestamp the creation of the history row, but it would also be interesting to be able to track the user responsible for the content update. I would like to get suggestions on the best way to achieve this. I realize this is somewhat outside the

Re: [sqlalchemy] Injecting User info into _history table to track who performed the change

). From there you can store the user either as a foreign key, > or a unique identifier like email. Which one you pick would depend on how > you want the history to be affected when you delete a user record for > example. > > > > On Fri, Mar 12, 2021 at 11:58 PM JPLaverdure wrote: >

Re: [sqlalchemy] Injecting User info into _history table to track who performed the change

ssion.info >> >> Then, in the before_flush event handler, I retrieve the request object >> from session.info, and then I can add whatever request-specific info I >> want to the DB. >> >> Simon >> >> On Sun, Mar 14, 2021 at 4:05 PM JPLaverdure