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 22, 2006, at 2:39 PM, Daniel Miller wrote:
# test create_metaclass
context = ThreadLocalSessionContext(objectstore.Session)
meta = create_metaclass(context)
class MyClass(object): __metaclass__ = meta
run_test(MyClass, context)
how about this:
import sqlal
Michael Bayer wrote:
actually, the semantics of import_() are much more equivalent to
hibernate's merge(), not update(). now update() makes more sense to me.
merge() sounds fine to me (better than import_() anyway). How would you do
something like Hibernate's update() with pre-0.2 SA?
sin
actually, the semantics of import_() are much more equivalent to
hibernate's merge(), not update(). now update() makes more sense to me.
since I desperately want this to just be done, i am considering just
throwing on very similar versions of load(), merge(), save(), update
(), saveOrUpdate
On Apr 21, 2006, at 12:32 AM, Robert Leftwich wrote:
Michael Bayer wrote:
to me, the method means, "this is an object I loaded from some
other Session and now I want it to be in this Session", thats why
I like "import"...it implies youre "taking it from somewhere else
and putting it he
Michael Bayer wrote:
to me, the method means, "this
is an object I loaded from some other Session and now I want it to be
in this Session", thats why I like "import"...it implies youre "taking
it from somewhere else and putting it here".
adopt?
Robert
-
i would think you didnt like add() but liked import(). what does the
name "update()" mean ? to me that means you want to issue an UPDATE
statement. but SA will not issue any UPDATE statements unless the
object is modified in some way. then you might say delete() on it
and then its not g
On 4/20/06, Daniel Miller <[EMAIL PROTECTED]> wrote:
> Yeah, I wasn't really suggesting that they be changed (although I don't like
> "import_").
I agree with you on this particular bikeshed. PEP8, I believe, does
mention that format, but it still seems ugly.
Kevin
Michael Bayer wrote:
hey Dan -
just FYI, the current 0.2 Session implementation regarding this is
looking like the following (hibernate's "save" is "add", hibernate's
"update" is "import_". both of which at the moment seem to be clearer
names to me, but maybe you see it differently...possib
hey Dan -
just FYI, the current 0.2 Session implementation regarding this is
looking like the following (hibernate's "save" is "add", hibernate's
"update" is "import_". both of which at the moment seem to be
clearer names to me, but maybe you see it differently...possibly not
consistent
Hello Daniel,
> I hate to sound like a broken record, but this is how Hibernate does it.
> New objects become associated with a session by calling session.save(obj),
> and objects that already exist in the database become associated with the
> session by calling session.update(obj). I wouldn't
Gustavo Niemeyer wrote:
Hey Michael,
0.2 would easily alllow you to do this:
e1 = create_engine('someengine1')
e2 = create_engine('someengine2')
s1 = Session(bind_to=e1)
s2 = Session(bind_to=e2)
This is looking very interesting already!
metadata =
Hey Michael,
> 0.2 would easily alllow you to do this:
>
> e1 = create_engine('someengine1')
> e2 = create_engine('someengine2')
>
> s1 = Session(bind_to=e1)
> s2 = Session(bind_to=e2)
This is looking very interesting already!
> metadata = MetaData()
> mytabl
hey gustavo -
0.2 would easily alllow you to do this:
e1 = create_engine('someengine1')
e2 = create_engine('someengine2')
s1 = Session(bind_to=e1)
s2 = Session(bind_to=e2)
metadata = MetaData()
mytable = Table('mytable', metadata, columns...)
Hi again Michael,
> I only had a brief look. However, the changes are making the whole
> thing more flexible than it was before, so I am sure your
> "engine-switching" scheme can be used. The MetaData which holds your
> tables can have its engine switched at any point, and the Session can
> also
Gustavo Niemeyer wrote:
> Have you had a chance to look at the message I've sent regarding
> the clustering scheme? Do you think something about the details
> I've explained could be considered in these changes or would it
> be too incompatible with the changes you're doing?
>
Gustavo -
I only h
Hello Michael,
(...)
> theres more you can do..the Session can bind different tables to
> different engines, it can bind to Connections instead of Engines, and
> the Session can provide a real transactional interface too. whats
> missing is, the docs, and also some convention on how these pattern
hey list -
i have committed my work on the 0.2 series so far to a branch in SVN.
this branch is available at:
http://svn.sqlalchemy.org/sqlalchemy/branches/schema
Its not all working yet. SQLite is up, Postgres is sort of up, the rest
still need some conversion. unittests are 50/50.
I woul
18 matches
Mail list logo
