On May 11, 2006, at 10:31 PM, Daniel Miller wrote:
I think by default it should require a session.save(u) before the
flush (that's exactly what Hibernate does).
its the default.
Now if someone happens to want that type of magic, then they can
use one of the _explicit_ recipes to get that
On May 12, 2006, at 12:10 PM, Robin Munn wrote:
"If you prefer to have one default session that all your objects are
associated with by default, then import the thread-local mod at the
start of your code. (Insert detailed instructions here). This will
give you one global session object, used au
Hey Mike,
Here's a new patch, which uses your mapper extension idea rather than the
session_context mapper() parameter. I also removed orm.session.current_session
and friends, and updated the unitofwork documentation accordingly.
Note that I have implemented the new mapper extension method you
On 5/11/06, Michael Bayer <[EMAIL PROTECTED]> wrote:
the "threadlocal" mod
has been removed from the tutorial as well as all mention of it.
For the sake of the people like me who learned SQLAlchemy in the 0.1.x
series, or the people who prefer the thread-local style of session
management, I thi
On May 14, 2006, at 1:42 AM, Daniel Miller wrote:
I'm not sure how many (if any) tests this may have broken. I've
always had problems trying to run the tests...is there anything
special I need to do? Give it a whirl and let me know what you think.
not every unit test has been converted to
This seemed to get lost in sourceforge's email queue, resending
On May 11, 2006, at 10:31 PM, Daniel Miller wrote:
I think by default it should require a session.save(u) before the
flush (that's exactly what Hibernate does).
its the default.
Now if someone happens to want that type of m
Michael Bayer wrote:
The mapper will have an optional session_context parameter. It will
provide the exact same functionality as current_session(), but
provides additional flexibility because each mapper can have it's own
context.
OK, so you want to put it in mapper, yes thats the other wa
Michael Bayer wrote:
we agree, that there should be some way to turn on this feature:
u = User()# 'u' is now automatically in the session
session.flush()# 'u' is now saved.
I think by default it should require a session.save(u) before the flush (that's
exactly what Hibernate
On May 11, 2006, at 12:03 AM, Daniel Miller wrote:
The thread-local mod is implied in all the documentation examples
for 0.2; therefore it will be used by most if not all SA users at
least at first. When a project starts to move from simple
experimentation mode into a full-blown complex p
On May 11, 2006, at 12:03 AM, Daniel Miller wrote:
As I've already said, I object to adding a __call__() method in
addition to the "current" property because it adds confusion about
the "one obvious way" to get the current session. The "reference
implementation" of your "session context" s
dan -
no need to get defensive, the list has had enough flame wars for one
day.
this session context stuff is so not a big deal. we can go around
and around, its not going to go anywhere until you answer me this
question:
we agree, that there should be some way to turn on this feature
Michael Bayer wrote:
On May 2, 2006, at 10:13 PM, Daniel Miller wrote:
If you're interested, I have lot's of comments like this on various
parts of the SQLAlchemy API.
im sure you do, but one thorny issue of SA is that it supports multiple
programming styles, particularly in 0.2, where y
That's a good point. Yes I agree, that solution is good (with the extra
None param in getattr of course). I would also do an explicit check for
None like this:
def default_session(obj=None):
default_session = getattr(obj, "__default_session__", None)
if default_session is not None:
> def default_session(obj=None):
> default_session = getattr(obj, "__default_session__")
That of course should include None as the third argument, otherwise
the AttributeError is raised as well.
--
Gustavo Niemeyer
http://niemeyer.net
---
On May 2, 2006, at 8:42 PM, Daniel Miller wrote:
Oh, and use a try/except block rather than hasattr. It's more
pythonic... So with all those suggestions this is what we end up with:
def default_session(obj=None):
try:
return obj.__default_session__()
except AttributeError:
On May 2, 2006, at 10:13 PM, Daniel Miller wrote:
If you're interested, I have lot's of comments like this on various
parts of the SQLAlchemy API.
im sure you do, but one thorny issue of SA is that it supports
multiple programming styles, particularly in 0.2, where you can use
an expli
> Right? Yes, that's fine. That (the first version) will work with
> either classmethod or instance method. I don't see much use in an
> instance method ATM, but you're right why not allow it? It will allow
> (tempt?) people to do things they shouldn't do, but hey this is Python
> and we're consent
Michael Bayer wrote:
also i dont understand how sticking a __call__() on SessionContext would
have any impact on its existing get/set/del operations.
It's totally unnecessary and it clutters the interface. Unnecessary methods/properties/etc. are
confusing because they make people wonder "
Michael Bayer wrote:
ive liked __session__ all along. Dan's concern is that people will
think __session__ returns the session which the instance is attached to,
not just the "contextual" session which may be different.
Yeah, I'm not thrilled about __session__ for that exact reason. However,
ive liked __session__ all along. Dan's concern is that people will
think __session__ returns the session which the instance is attached
to, not just the "contextual" session which may be different.
In my original proposal, i was going to just have __session__ just
return wahtever contextu
> how about 'contextualsession' or somethingI really dislike the
> name "contextsession".
__session__ would probably be fine, unless you're afraid to conflict
with something else. We use __int__ to get ints out of an object,
__nonzero__ to get a boolean, and so on. Using __session__ looks li
> So would it work like this:
>
> callable = MyClass.__sessioncontext__
> session = callable()
>
> or like this:
>
> callable = MyClass.__sessioncontext__()
> session = callable()
>
> I'm not really liking the second one because it requires this to get a
> session directly from the object:
>
how about 'contextualsession' or somethingI really dislike the
name "contextsession".
also i dont understand how sticking a __call__() on SessionContext
would have any impact on its existing get/set/del operations.
On May 1, 2006, at 9:45 PM, Daniel Miller wrote:
Michael Bayer wrote:
Michael Bayer wrote:
I havent done anything with SessionContext as of yet, but i had in mind
that __sessioncontext__ would return a callable. when you call that
returned callable, you get the session.
So would it work like this:
callable = MyClass.__sessioncontext__
session = callable()
dan -
great news, I can continue building on what we've been doing.
I havent done anything with SessionContext as of yet, but i had in
mind that __sessioncontext__ would return a callable. when you call
that returned callable, you get the session. on SessionContext this
would mean just
Michael Bayer wrote:
On Apr 27, 2006, at 11:05 PM, Daniel Miller wrote:
the __session__() method is only called to get a session, *when the
instance is not already associated with a session*. this method is
merely there as the standard way to plug into systems such as the
SessionContext
> my current proposal regarding the association of objects to sessions,
> as well as the optional association of objects and classes to
> "session contexts", is as follows:
(...)
That's very nice! I'm looking forward to refactor our application
to use this interface.
> # returns the ses
On Apr 27, 2006, at 11:05 PM, Daniel Miller wrote:
I assume you're implicitly referring to any method that would call
Session._bind_to(). Personally, I think Session._bind_to() should
raise an exception if the object-to-be-bound is associated with
some other _open_ session (rather than sile
Michael Bayer wrote:
my current proposal regarding the association of objects to sessions, as
well as the optional association of objects and classes to "session
contexts", is as follows: ...
Great! this looks pretty good.
I do have a few comments on your other email though. Here goes...
my current proposal regarding the association of objects to sessions,
as well as the optional association of objects and classes to
"session contexts", is as follows:
Session - represents a current unit of work session and an
associated collection of objects. a particular object is only i
30 matches
Mail list logo
