Path: csiph.com!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!newsfeed.eweka.nl!eweka.nl!feeder3.eweka.nl!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.006 X-Spam-Evidence: '*H*': 0.99; '*S*': 0.00; 'python,': 0.02; 'syntax': 0.03; 'classes.': 0.07; 'debugging.': 0.07; '**kwargs):': 0.09; 'kwargs': 0.09; 'orm': 0.09; 'def': 0.10; 'passing': 0.15; 'dictionaries': 0.16; 'programmer,': 0.16; 'rdbms': 0.16; 'side.': 0.16; 'skip:[ 60': 0.16; 'subject:Object': 0.16; 'subject:access': 0.16; 'instance,': 0.17; 'message-----': 0.17; '(in': 0.18; 'examples': 0.18; 'app': 0.19; 'to:name:python-list@python.org': 0.20; 'fairly': 0.21; 'to:2**1': 0.23; "i've": 0.23; 'header:In- Reply-To:1': 0.25; 'creating': 0.26; 'separate': 0.27; 'question': 0.27; 'skip:e 30': 0.27; "doesn't": 0.28; 'url:mailman': 0.29; 'case,': 0.29; 'convert': 0.29; 'objects': 0.29; '"the': 0.29; 'skip:_ 10': 0.29; 'probably': 0.29; 'class': 0.29; "i'm": 0.29; 'classes': 0.30; 'query': 0.30; 'returned': 0.30; 'subject: ?': 0.30; 'basic': 0.30; 'code': 0.31; 'point': 0.31; 'url:python': 0.32; 'skip:- 10': 0.32; 'could': 0.32; 'url:listinfo': 0.32; 'subject:data': 0.33; 'to:addr:python-list': 0.33; 'list': 0.35; 'generic': 0.35; 'requiring': 0.35; 'something': 0.35; 'received:org': 0.36; 'subject:': 0.36; 'but': 0.36; 'url:org': 0.36; 'email addr:python.org': 0.36; "didn't": 0.36; 'client': 0.36; 'charset:us-ascii': 0.36; 'why': 0.37; 'drop': 0.37; 'sent:': 0.37; 'quite': 0.37; 'data': 0.37; 'subject:: ': 0.38; 'from:': 0.38; 'easier': 0.38; 'fact': 0.38; 'object': 0.38; 'some': 0.38; 'nothing': 0.38; 'sure': 0.38; 'to:addr:python.org': 0.39; 'received:192': 0.39; 'received:192.168': 0.40; 'url:mail': 0.40; 'your': 0.60; 'customer': 0.61; 'received:216': 0.62; 'back': 0.62; 'email name:python-list': 0.62; 'situation': 0.62; 'techniques': 0.63; 'email addr:gmail.com': 0.63; 'more': 0.63; 'august': 0.66; 'account.': 0.83; '(they': 0.84; 'amazing,': 0.84; 'subject:good': 0.84; 'dealt': 0.91 From: "Sells, Fred" To: "shearichard@gmail.com" , "python-list@python.org" Subject: RE: Object Models - decoupling data access - good examples ? Thread-Topic: Object Models - decoupling data access - good examples ? Thread-Index: Ac1yusxtssk2J695QMSxl6eRk+lAFgB98Eqw Date: Tue, 7 Aug 2012 15:46:44 +0000 References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.218.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 58 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1344354476 news.xs4all.nl 6892 [2001:888:2000:d::a6]:59494 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:26724 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 cla= sses. I found it easier to separate these. I would then create basic methods like EditStaff.add_empooyee(**kwargs) in= side of which I would drop into (in my case) MySQLdb. In retrospect, I'm n= ot sure that the generick use of **kwargs was a good solution in that it ma= sked what I was passing in, requiring me to go back to the calling code whe= n debugging. OTOH it allowed me to be pretting generic by using Sql =3D sql_template % kwargs On the query side. I would convert the returned list of dictionaries to a l= ist 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 o= f the sophisticated techniques of others on the mailing list so take that i= nto account. Fred. -----Original Message----- From: python-list-bounces+frsells=3Dadventistcare.org@python.org [mailto:py= thon-list-bounces+frsells=3Dadventistcare.org@python.org] On Behalf Of shea= richard@gmail.com Sent: Saturday, August 04, 2012 11:26 PM To: python-list@python.org Subject: Re: Object Models - decoupling data access - good examples ? =20 >=20 > Just out of curiosity, why do you eschew ORMs? >=20 Good question ! I'm not anti-ORM (in fact in many circs I'm quite pro-ORM) but for some tim= e 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).=20 I was interested to know, given that was the case, how you might - in Pytho= n, 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. --=20 http://mail.python.org/mailman/listinfo/python-list