Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #26724
| From | "Sells, Fred" <fred.sells@adventistcare.org> |
|---|---|
| Subject | RE: Object Models - decoupling data access - good examples ? |
| Date | 2012-08-07 15:46 +0000 |
| References | <ebb88ade-7598-46b1-8fb6-fd7f7430b296@googlegroups.com><roy-C112B6.21172104082012@news.panix.com> <bf551938-0b08-46d5-82be-812c3521a0cd@googlegroups.com> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.3059.1344354475.4697.python-list@python.org> (permalink) |
Given that "the customer is always right": In the past I've dealt with this situation by creating one or more "query" classes and one or more edit classes. I found it easier to separate these. I would then create basic methods like EditStaff.add_empooyee(**kwargs) inside of which I would drop into (in my case) MySQLdb. In retrospect, I'm not sure that the generick use of **kwargs was a good solution in that it masked what I was passing in, requiring me to go back to the calling code when debugging. OTOH it allowed me to be pretting generic by using Sql = sql_template % kwargs On the query side. I would convert the returned list of dictionaries to a list of objects using something like Class DBrecord: Def __init__(self, **kwargs): Self.__dict__.update(kwargs) So that I did not have to use the record['fieldname'] syntax but could use record.fieldname. I would describe myself as more of a survivalist programmer, lacking some of the sophisticated techniques of others on the mailing list so take that into account. Fred. -----Original Message----- From: python-list-bounces+frsells=adventistcare.org@python.org [mailto:python-list-bounces+frsells=adventistcare.org@python.org] On Behalf Of shearichard@gmail.com Sent: Saturday, August 04, 2012 11:26 PM To: python-list@python.org Subject: Re: Object Models - decoupling data access - good examples ? > > Just out of curiosity, why do you eschew ORMs? > Good question ! I'm not anti-ORM (in fact in many circs I'm quite pro-ORM) but for some time I've been working with a client who doesn't want ORMs used (they do have quite good reasons for this although probably not as good as they think). I was interested to know, given that was the case, how you might - in Python, go about structuring an app which didn't use an ORM but which did use a RDBMS fairly intensively. I take your point about having "rolled my own ORM" - lol - but I can assure you what's in that 'bardb' is a pretty thin layer over the SQL and nothing like the, pretty amazing, functionality of, for instance, SQLAlchemy. -- http://mail.python.org/mailman/listinfo/python-list
Back to comp.lang.python | Previous | Next — Previous in thread | Find similar | Unroll thread
Object Models - decoupling data access - good examples ? shearichard@gmail.com - 2012-08-04 17:04 -0700
Re: Object Models - decoupling data access - good examples ? Roy Smith <roy@panix.com> - 2012-08-04 21:17 -0400
Re: Object Models - decoupling data access - good examples ? shearichard@gmail.com - 2012-08-04 20:26 -0700
Re: Object Models - decoupling data access - good examples ? Roy Smith <roy@panix.com> - 2012-08-05 09:04 -0400
Re: Object Models - decoupling data access - good examples ? Adam Tauno Williams <awilliam@whitemice.org> - 2012-08-07 09:00 -0400
RE: Object Models - decoupling data access - good examples ? "Sells, Fred" <fred.sells@adventistcare.org> - 2012-08-07 15:46 +0000
csiph-web