RE: Object Models - decoupling data access - good examples ?
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@python.org [mailto:python-list-bounces+frsells=adventistcare@python.org] On Behalf Of shearich...@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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Models - decoupling data access - good examples ?
On Sat, 2012-08-04 at 20:26 -0700, shearich...@gmail.com wrote: > > > > 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). So call the ORM something else. > 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. You'd reinvent the ORM calling it something else - because an ORM is what you are describing. This is just a case of those-who-will-not-use-are-doomed-to-recreate. > 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. This implies that SQLAlchemy is 'fat'. I don't see any evidence of that. It is comprehensive so when you encounter something you can be confident it is up to the challange. signature.asc Description: This is a digitally signed message part -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Models - decoupling data access - good examples ?
In article , shearich...@gmail.com wrote: > > 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). OK, I'll re-ask the question. What are the reasons? > 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. So, you're opposed to ORMs in general because you find SQLAlchemy too heavyweight. I don't blame you; every time I look at SQLAlchemy, I go screaming in the other direction. But, there are other ORMs. See, for example, http://lmgtfy.com/?q=python+orm. -- http://mail.python.org/mailman/listinfo/python-list
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
Re: Object Models - decoupling data access - good examples ?
In article , shearich...@gmail.com wrote: > I should say I'm talking relational database here and, for various reasons, > ORMs are not involved. Just out of curiosity, why do you eschew ORMs? On the other hand, you really haven't. All you've done is rolled your own. So, the real question is, why do you want to roll your own ORM instead of using some existing one? -- http://mail.python.org/mailman/listinfo/python-list
