[sqlalchemy] Re: Design: mapped objects everywhere?
Yowser. Thanks to both of you - that's exactly what I mean. Any pointers on where I can find an example of a class that is unaware if it is in the db? Or is there a good example of the second solution, of a single class that does the what and why, and an interchangeable layer/context that does load/saving? I'm digging through dbcook.sf.net but haven't found anything just yet. On 2007 Dec 7, at 22:07, [EMAIL PROTECTED] wrote: Paul Johnston wrote: A Sample may be created by the web application or fetched from the database. Later on, it may be disposed of, edited or checked back into the db. Sounds like you want your app to be mostly unaware of whether a class is saved in the db or not (i.e. persistent)? If so, I'd use a single class, design the properties so they work in non-persistent mode, and then they'll work in persistent mode as well. or like a single class that does the what and why, and an interchangeable layer/context that does load/saving (and the relations!). in such situations declarative programming helps a lot, so u dont bind your self to (the) db (or whatever persistency). Check dbcook.sf.net. My own latest experience is about turning a project that was thought for db/using dbcook into non-db simple-file-based persistency. The change was relatively small, like 5-10 lines per class - as long as there are Collections etc similar notions so Obj side of ORM looks same. -- Dr Paul-Michael Agapow: VieDigitale / Inst. for Animal Health [EMAIL PROTECTED] / [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Design: mapped objects everywhere?
On Monday 10 December 2007 12:12:19 Paul-Michael Agapow wrote: Yowser. Thanks to both of you - that's exactly what I mean. Any pointers on where I can find an example of a class that is unaware if it is in the db? Or is there a good example of the second solution, of a single class that does the what and why, and an interchangeable layer/context that does load/saving? I'm digging through dbcook.sf.net but haven't found anything just yet. well... good example - no. there is a bad example: dbcook/dbcook/usage/example/example1.py The classes are plain classes (.Base can be anything/object), with some DB-related declarations/metainfo in them. they do not have to know that they are DB-related. if u dont give them to dbcook.builder.Builder, they will not become such. If u give them, they will become SA-instrumented etc, but u still do not have to change anything - as long as your methods do not rely (too much) on being (or not being) DB. see dbcook.expression as attempt to wrap some queries in independent manner. more, if u redefine the Reflector u can have different syntax for db-metainfo - or get it from different place, not at all inside the class. So u can plug that in and out whenever u decide to (no example on this, its theoretical ;-). Still, the final class (or object) will be always aware about being in the db or not; it is _you_ who should know when u do not care (95%) and when u do (5%). All this is proper design and then self-discipline issue: u have to keep the things separate (and i tell u, it is NOT easy) if u start putting it any db-stuff in the classes, no framework will help u. complete opaque separation is probably possible, but will probably mean having 2 paralel class hierarchies instead of one. On 2007 Dec 7, at 22:07, [EMAIL PROTECTED] wrote: Paul Johnston wrote: A Sample may be created by the web application or fetched from the database. Later on, it may be disposed of, edited or checked back into the db. Sounds like you want your app to be mostly unaware of whether a class is saved in the db or not (i.e. persistent)? If so, I'd use a single class, design the properties so they work in non-persistent mode, and then they'll work in persistent mode as well. or like a single class that does the what and why, and an interchangeable layer/context that does load/saving (and the relations!). in such situations declarative programming helps a lot, so u dont bind your self to (the) db (or whatever persistency). Check dbcook.sf.net. My own latest experience is about turning a project that was thought for db/using dbcook into non-db simple-file-based persistency. The change was relatively small, like 5-10 lines per class - as long as there are Collections etc similar notions so Obj side of ORM looks same. -- Dr Paul-Michael Agapow: VieDigitale / Inst. for Animal Health [EMAIL PROTECTED] / [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Design: mapped objects everywhere?
Hi, A Sample may be created by the web application or fetched from the database. Later on, it may be disposed of, edited or checked back into the db. On the other hand, the requirements and coding of both classes are kinda different, and I find myself changing the properties of the mapped class for better mapping and making the use of the class in non-Db contexts more awkward. Sounds like you want your app to be mostly unaware of whether a class is saved in the db or not (i.e. persistent)? If so, I'd use a single class, design the properties so they work in non-persistent mode, and then they'll work in persistent mode as well. Paul --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Design: mapped objects everywhere?
Paul Johnston wrote: Hi, A Sample may be created by the web application or fetched from the database. Later on, it may be disposed of, edited or checked back into the db. On the other hand, the requirements and coding of both classes are kinda different, and I find myself changing the properties of the mapped class for better mapping and making the use of the class in non-Db contexts more awkward. Sounds like you want your app to be mostly unaware of whether a class is saved in the db or not (i.e. persistent)? If so, I'd use a single class, design the properties so they work in non-persistent mode, and then they'll work in persistent mode as well. or like a single class that does the what and why, and an interchangeable layer/context that does load/saving (and the relations!). in such situations declarative programming helps a lot, so u dont bind your self to (the) db (or whatever persistency). Check dbcook.sf.net. My own latest experience is about turning a project that was thought for db/using dbcook into non-db simple-file-based persistency. The change was relatively small, like 5-10 lines per class - as long as there are Collections etc similar notions so Obj side of ORM looks same. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
