Re: [sqlalchemy] Re: mapping without key
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 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 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.
[sqlalchemy] Re: mapping without key
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 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 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.
[sqlalchemy] Re: mapping without key
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 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.
