EnhancedObject: Yet Another Python ORM (an RFC)

[eduardo.padoan]

I have some ideas about a ORM design, but have no time to start its
development.
I used SQLObject, Django's Model, and looked at SQLAlchemy and Dejavu,
an readed some thread in the last year or so.
Here is an example:

#from EnhancedOcject.all import *
from EnhancedObject.core import EObject, EType, EPersistModel,
EMetaType # EMetaType => EType
from EnhancedObject.utils import e_apply
## map attributes to fields - All Inheriting from EAttribute
from EnhancedObject.basic import EInt, EStr, EUni, EFloat #
python_types->db_types Bridges
from EnhancedObject.datime import EDate, ETime, EDateTime #
python_libs->db_types Bridges
from EnhancedObject.relat import EComposition, EAgregation,
EAssociation
# EAssociation SubClasses by multiplexity
from EnhancedObject.relat import EHasMany, EHasA

MyEType = __metaclass__ = EMetaType(engine="postgre", dbname="foo")) #
Right place to do that?

# EPersistModel: EFields? EPersistAttribs? EAttrsToFields? EMetaTable?
ETableModel?
func_table = EPersistModel(name=EStr(maxlen=50, required=True),
salary=EFloat(currency=True,
maxval=1000.00),
hired=EDate(required=True))
sector_table = EPersistModel(name=EStr(maxlen=25, required=True))

class Person:
# persist_model inherited as False - non-persistent objects
def do_things_people_do(self):
pass


class Func(Person):
persist_model = func_table
sector = EAssociation('Sector', mult=1) # Multiplexities = 1..* =
(1,)
# 0..1 =
(0, 1)
# 0..* =
(0,)
# etc...
def __init__(**kw):
## Just a litle convenience, the same as:
## self.name, self.hired, self.salary = name, hired, salary
## but with the meth. sig. as:
## def __init__(self, name, hired, salary=500.00)
e_apply(self, kw, ['name', 'hired', ('salary', 500.00)])
## raises an exception when 'name' or 'hired' is not found in
kw
## raises an warning when an key in kw is not in the list

class Sector:
persist_model = sector_table
funcs = EAssociation('Func', mult=(1,))
def __init__(**kw):
e_apply(self, kw, 'name')

for table in MyEType.instances: # instaces: an iterable
(EObjInstancesManager instance)
if table.persist_model:
table.create_table()
## OR
MyEType.instances.create_tables()

## TODO: Inheritance beetween persistent classes
## How will this work? the must util and consistent way

s1 = Sector("IT")
f1 = Func(name="Gornivaldo Plezituso", hired=date.now(), sector=s1)

list("#%i:%d" % (i, name) for name in enumerate(f1.instances)) # =>
["#1: Gornivaldo Plezituso"]

# Lets Query!
# q_: query methods for each persistent instance attribute in the
related EObjInstancesManager
# returns an EQuery object, that has q_ methods too, to refine the
search
# lazyness: only executes the query when iterated or indexed:
f1 = Func.instances.q_name(eq="Gornivaldo
Plezituso").q_hired(le=date,now)[0]
# eq, diff, gt, lt, le, ge, starts_with,
ends_with, etc

 

[eduardo.padoan]

Ops, sorry about my ugly english.

 

[fumanchu]

I have some ideas about a ORM design,
but have no time to start its development.

So why tell us? What are your ideas? What does your design do that the
others don't?


Robert Brewer
System Architect
Amor Ministries
(e-mail address removed)

 

[Bruno Desthuilliers]

I have some ideas about a ORM design, but have no time to start its
development.
I used SQLObject, Django's Model, and looked at SQLAlchemy and Dejavu,
an readed some thread in the last year or so.

Wouldn't it be better to try and make the relationel model directly
available into Python (which SQLAlchemy somewhat try to do AFAICT)
instead on insisting on 'domain-object'<->RDBMS tuple mapping ?

my 2 cents...

(snip)

 

[eduardo.padoan]

So why tell us? What are your ideas? What does your design do that the

others don't?

Basically, the API I exemplificated in the first exemple. My initial
idea was to have a way of turn alread designed objects into persistent
ones. This is not the goal of SQLObject, for example.
Other litle difference is the 'multiplexity' (mult) argument in the
EAssociation.

 

[fumanchu]

Basically, the API I exemplificated in the first exemple. My initial
idea was to have a way of turn alread designed objects into persistent
ones. This is not the goal of SQLObject, for example.

No, but it is a design point of Dejavu.

Other litle difference is the 'multiplexity' (mult) argument in the
EAssociation.

EAssociation -> HasA and HasMany? How is that different from Dejavu's
UnitAssociation -> ToOne and ToMany?


Robert Brewer
System Architect
Amor Ministries
(e-mail address removed)

 

[eduardo.padoan]

No, but it is a design point of Dejavu.

EAssociation -> HasA and HasMany? How is that different from Dejavu's
UnitAssociation -> ToOne and ToMany?

Hum, I'll give Dejavu and SQLALchemy a better look, with sure. I should
be feeling like this guy now:
http://nerd.newburyportion.com/2005/11/everybodys-got-an-orm