Thanks. Model that we work with has tables, which have no unique constraints. Keys can be inferred from data contained specified in ORM maping but there is no guarantee that this will always work because data may change. Still one could argue a case where mapping such table to a class has merit even if far removed from all the benefits of SQLAlchemy ORM.
On Jun 6, 4:55 pm, Michael Bayer <[email protected]> wrote: > There's two variants to this question, and I can't tell which one you're > asking for. > > If the views in question do in fact have candidate keys, that is, columns > which uniquely identify a row, you just specify those either to the Table or > mapper() as the columns that uniquely identify the row. They don't have to > be considered "primary" by the database in any formal way. > > If OTOH you have views which truly have duplicate rows and no candidate key > of any kind, the ORM won't do that. As you probably know, the primary key > thing is more or less the spine of mapper() and Query, and there's really no > way the ORM could be refactored, without a great loss of stability and > performance, to make this requirement optional. > > If you're looking for duplicate rows to come back as individual objects, > Query() can be handed Table objects to load rows from, so a custom Query > subclass that wraps named tuples into objects could possibly approximate this > effect. > > On Jun 6, 2012, at 3:01 PM, Victor Olex wrote: > > > > > > > > > With the understanding that we would loose the ability to properly > > track the sate of a mapped object and ability to update or insert in > > ORM and likely the ability to correctly use relationships as well - > > how can one accomplish a mapper, which would work on tables (views) > > without any key, which uniquely identify records in it? > > > The rationale for this question is to be able to be able to operate on > > these tables in object (ORM) context and to join them in queries with > > other normally mapped classes for reading purposes only. The ideal > > solution would be perhaps a different Declarative Base class using a > > modified mapper. > > > -- > > You received this message because you are subscribed to the Google Groups > > "sqlalchemy" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/sqlalchemy?hl=en. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
