On Mar 17, 2006, at 11:09 AM, Qvx 3000 wrote:
The idea is not to keep JOB_ID in dozen tables that have some work
performed on them. The reasons are that there are maybe more
different jobs that coud be performed on the table (IMPORT,
AUTOJOIN, BILLING, ...) or som of the jobs can be performed more
than once. So I keep relation data directly inside JOB table inside
SOURCE_TYPE and SOURCE_REF columns. So I cannot say that
SOURCE_TYPE/SOURCE_REF is foreign key to any particular table.
OK, so your database is not normalized. which will make the job
harder for an ORM which expects normalization. but like we went over
earlier, you can set up whatever join conditions you want without any
real foreign keys present.
Is there a way to somehow move my create_campaign() function inside
Campaign.__init__? It is not wery important, more the matter of style.
sure you can just say:
class Campaign(object):
def __init__(self):
self.id = Campaign.c.id.default.scalar()
looks pretty stylish to me... :)
Well, maybe the simplest answer is that those proceures are used
from other systems as well (like Oracle forms). It is an existing
system and it seemed inapropriate to duplicate the functionality in
another place. This concrete app that I'm doing now is actually a
webapp used to connect three different systems each with its own
functionality. Another thing is that there are maybe other
applications comming that will be using same procedures (we are
evaluating different web frameworks by building the same web app).
yah youve got a system that is stored-procedure based, and that is
basically the persistence interface to your application. I would
keep relying upon those stored procs to do the work, and write a
Python layer that deals with those procedures generically....you
shouldnt have to "write the same thing over and over", you should
establish the pattern and write some common library that just handles
it. Im not sure you want to be using the Unit of Work idea at
all..the main thing UOW gives you is the ability to sort dependencies
to allow saving them/updating shared data in the correct order. If
your procs already do that, then it might not be worth it.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
