I have just started working on another kind of declarative layer for
SQLalchemy. Infact it is more like a domain specific language for
setting up basic form orientated databases for small charities in
order to provide viable alternative to Access for simple information
storage needs. The details
i guess you just shouldn't override the constructor of DeclartiveBase,
because it did some keyword args magic inside the constructor.
On Jul 12, 12:20 am, Heston James - Cold Beans
[EMAIL PROTECTED] wrote:
if u look up the stacktrace/traceback, u'll see which statement in
your own code
Michael, why don't change the 'Column' class values to *nullable =
False, default=''* ?
After of reading the down articles I think that set NULL to False by
default will avoid possible errors to many people.
NULL means something is unknown. [1]
NULL needs to be used with prudence and with
Insert into myisam table worked because
it does not support transactions?
Yes, to my knowledge mysql with myiasm tables will accept, but ignore any
'begin transaction' or 'commit transaction' statements: they are no-ops.
--~--~-~--~~~---~--~~
You received this
well, yet another, wellcome to the pack...
have a look at (my) dbcook.
http://dbcook.sourceforge.net/readme
either on pypi or direct svn co
https://dbcook.svn.sourceforge.net/svnroot/dbcook/trunk
or even more things at
https://dbcook.svn.sourceforge.net/svnroot/dbcook
my opinion on validation
I can't figure out any good way to phrase my question without some
pipe-laying, so here I go...
I have a pattern of doing some various query activities in my app that
ultimately result in retrieving a single instance of one of my mapped
classes from the ORM. So naturally I stuck that pattern in
Well, the programs has backward incompatibility prior version 1.0
On Jul 12, 5:46 pm, Rick Morrison [EMAIL PROTECTED] wrote:
This would be very ugly for backward compatibility. If you want non-null,
then just say so in your metadata. Jamming relational design dogma down
everyone's throat is
On Saturday 12 July 2008 20:57:01 Kyle Schaffrick wrote:
I can't figure out any good way to phrase my question without some
pipe-laying, so here I go...
I have a pattern of doing some various query activities in my app
that ultimately result in retrieving a single instance of one of my
hi
i see in the src that the column-default function can be a no-args, or
taking one arg - some context. Is this last one official (it's not in
the docs), and what sort of context that is? some sort of
base.ExecutionContext?
svilen
--~--~-~--~~~---~--~~
You
On Saturday 12 July 2008 23:02:15 Rick Morrison wrote:
I've been thinking about a feature like this for some time as well,
but haven't found the right way to describe it. Seems like it's
time to take a stab at it. This is likely to be half-baked at best:
It's something in between a full
On Jul 12, 2008, at 8:59 AM, satoru wrote:
i guess you just shouldn't override the constructor of DeclartiveBase,
because it did some keyword args magic inside the constructor.
declarative places a convenience __init__ that installs keywords as
attributes, but you're free to override
On Jul 12, 2008, at 9:40 AM, kindly wrote:
I have just started working on another kind of declarative layer for
SQLalchemy. Infact it is more like a domain specific language for
setting up basic form orientated databases for small charities in
order to provide viable alternative to Access
On Jul 12, 2008, at 11:42 AM, Kless wrote:
Michael, why don't change the 'Column' class values to *nullable =
False, default=''* ?
After of reading the down articles I think that set NULL to False by
default will avoid possible errors to many people.
NULL means something is unknown. [1]
On Jul 12, 2008, at 3:45 PM, [EMAIL PROTECTED] wrote:
hi
i see in the src that the column-default function can be a no-args, or
taking one arg - some context. Is this last one official (it's not in
the docs), and what sort of context that is? some sort of
base.ExecutionContext?
the
On Jul 12, 2008, at 1:57 PM, Kyle Schaffrick wrote:
I can't figure out any good way to phrase my question without some
pipe-laying, so here I go...
I have a pattern of doing some various query activities in my app that
ultimately result in retrieving a single instance of one of my mapped
On Jul 12, 2008, at 4:02 PM, Rick Morrison wrote:
SA already has most of the join aliasing machinery to issue such a
query and do the in-memory join. But..the problem is
restricting the set of 'children' to match those of 'vector' -- the
seemingly easiest thing would be to use a
On Sat, 12 Jul 2008 16:02:15 -0400
Rick Morrison [EMAIL PROTECTED] wrote:
Suppose you have a list result of a simple query:
vector = S.query(MappedObj).filter(foo).all()
and assume MappedObj has a simple relation children, each of those in
turn having a simple relation
On Sun, 13 Jul 2008 00:18:35 -0400
Kyle Schaffrick [EMAIL PROTECTED] wrote:
To setup the eagerness of cs at the exact point of lazy load,
the public API that allows this is via lazy='dynamic', which would
allow:
a = sess.query(A).first()
print a.bs.option(eagerload('cs')).first()
On Sat, 12 Jul 2008 22:01:50 +0300
[EMAIL PROTECTED] wrote:
after the Query is long gone?
if it is really gone/done, who should eager-load?
I assume that it would be possible to do it after the Query is gone, at
least in theory, since lazy-loaded attributes are able to trigger
eager-loads
19 matches
Mail list logo
