well yeah like I said I think you need to subclass Query first off, then intercept your special entities in the constructor and do special processing in __iter__.
On Jun 6, 2012, at 5:55 PM, Victor Olex wrote: > To be clear this is not a feature request. I could use a hit how to > build a fake mapper like this if not compatible in certain cases. > > On Jun 6, 5:52 pm, Victor Olex <victor.o...@vtenterprise.com> wrote: >> 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 <mike...@zzzcomputing.com> 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 sqlalchemy@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> sqlalchemy+unsubscr...@googlegroups.com. >>>> 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 sqlalchemy@googlegroups.com. > To unsubscribe from this group, send email to > sqlalchemy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
