Michael Bayer wrote:
how about this:
import sqlalchemy.ext.sessioncontext as sessioncontext
context = sessioncontext.ThreadLocalSessionContext()#
create_session is the default factory
class Foo(object):
__metaclass__ = context.metaclass
class Bar(object
On Apr 23, 2006, at 6:45 PM, Jonathan Ellis wrote:
Well I also think people should tell me what they think of
thatits essentially more monkeypatching.
Well, it comes down to the usual trade-offs, right? How hard is
it to accomplish w/o monkeypatching, and how likely is it to screw
so
theres a flag for that you can use, which I personally dont like but
it seems to be popular...
well I dont know the flag, but if you make a file setup.cfg with this
in it:
[egg_info]
tag_build = dev
tag_svn_revision = true
itll install it with the revision number.
theres something funny there, i just committed another fix for that
in 1334, the lazyloader was reversing the criterion if it was
backwards, since it wants the ? to be on the right side. but it
deosnt know how to reverse ">=" etc. so i just took the reverse out,
i dont think its necessary
On 4/24/06, Gambit <[EMAIL PROTECTED]> wrote:
As a side note, I always put the revision number (1333, etc) in the versionstring. This helps me keep track of what version I'm using at any given time,and also makes it easy to roll between discrete versions (instead of trying to
remember wtf it was y
youve got the identical code on both sides, right ? the "foreignkey"
thing shouldnt be needed, it implies something is not correct
elsewhere. are you using tables with autoload=True ?
On Apr 24, 2006, at 5:29 PM, Gambit wrote:
Hey Mike,
Interesting - in my demo environment it appears to
Hey All,
Outpacing myself a bit: if I reverse the query in the sample program to a
similar format:
Relation.mapper.add_property('datas', relation(Data.mapper,
primaryjoin=and_(Relation.c.info_pk==Data.c.info_pk,
Relation.c.start <= Data.c.timeval,
Relation.c.fin
Hey Mike,
Interesting - in my demo environment it appears to work fine. However, in my
production environment it actually reverses the parameters!
The actual property looks like this:
CoreDb.CustomerTour.mapper.add_property('equipment_history',
DB.relation(CheckoutEntry.mapper,
primaryjoi
Hey All -
I'm sure most of you know this already, but in case anyones wondering why the
pdb debugging wasn't working -- if you edit the 'setup.py' file pulled from
subversion and add: "zip_safe = False," to the setup function call, it'll keep
things nice and separated in directory form, which make
Hey Mike,
Brilliant as always!
Care to hazard a guess as to what's with the sketchily required foreignkey
field?
-G
On Monday, April 24, 2006, 9:24:58 PM, you wrote:
> gambit -
> the SQL clause it generates for the lazy criterion has the column
> "timeval" in it twice, which resulted in a na
we have a bunch of folks who are very opposed to anything "global" at
all. SA 0.2 abstracts the Engine away from the Table by using a
MetaData object, which is just a collection of Table objects, and may
or may not be connected to an Engine. an available subclass of
MetaData is DynamicMe
Qvx wrote:
"global" part from global_connect name just raised an alarm signal
inside my
head. If I'm reading you correct, global_connect will make it
impossible to
use more than one database. I hope I'm missing something obvious.
What is wrong with __engine__ module variable?
If it is possi
gambit -
the SQL clause it generates for the lazy criterion has the column
"timeval" in it twice, which resulted in a name collision for the
bind parameter names that gets munged upon compilation (i.e.
data_timeval, data_timeval_1), so that the lazy loader was not
setting the parametrs pr
On 4/23/06, Jonathan LaCour <[EMAIL PROTECTED]> wrote:
Also, I moved ActiveMapper to always use the default engine, as there were a lot of hacks inside ActiveMapper to allow for engine swapping. The use of the default engine and the "global_connect" functionality
significantly imp
14 matches
Mail list logo
