[OT] SQL-records and OOP

Terry Hancock hancock at anansispaceworks.com
Wed Jun 1 15:50:34 EDT 2005


On Monday 30 May 2005 04:35 am, egbert wrote:
> Each row of an sql table may be the data_part_in_spe  
> of some class_instance.
> I try to think about, and am looking for, the do's and don'ts 
> and caveat's and the right way of thinking about this transformation.
> For me it is new territory.
> 
> For instance, my sql-query produces much more rows than I am 
> interested in eventually. So I have to narrow this collection.
> 
> I can inspect the data while it is still a list of rows,
> and make instances of only the rows I really need.
> Or I may create an aggregate of full-blown instances derived
> from all the selected rows.

Zope has (or had) an object called a "Pluggable Brain" that was
for this kind of use, but I found that, outside of "through the
web programming" in Zope, it was more trouble than it was worth.

The simplest approach is to define the class without any data
or with default data.   Parse and reduce your rows, then return
a list of objects by wrapping the data:

class SmartRow:
    a, b, c = 0,0,0
    def __init__(self, rowdata):
        self.a, self.b, self.c = rowdata

# [...]
dumb_data = select_rows_you_need()
smart_data = [SmartRow(r) for r in dumb_data]

I don't think there's really much overhead in creating Python
classes.  In any case, it's never been an issue for me. But I'd
still recommend only wrapping the data after you've already
reduced the number of rows as much as possible.

Cheers,
Terry

 
--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com




More information about the Python-list mailing list