[sqlalchemy] Re: a way to share Session.mapper(SomeObject) across two scoped sessions?
On Jan 25, 2008 9:18 PM, Michael Bayer [EMAIL PROTECTED] wrote: On Jan 25, 2008, at 2:02 PM, Kumar McMillan wrote: On Jan 25, 2008 11:58 AM, Michael Bayer [EMAIL PROTECTED] wrote: The Session.mapper function is not worth it, in my opinion, it exists due to the sheer popularity of its previous incarnation, assign_mapper. I much prefer keeping things explicit. I can understand that. I am trying to get this working for an application that has its entire model declared in Elixir already. I like how easy Elixir is and so I'd rather not abandon that layer. But, there is probably a way to configure Elixir for save_on_init=False, I will give it a go. You can provide your own session (configured as you wish) to Elixir. Only the default provided session (it's there for your convenience only but you can perfectly not use it) use Session.mapper (and hence the save_on_init thing). elixir shouldn't be dependent on Session.mapper, if it is, I would advise the elixir folks change that requirement ASAP. in my view, at this point elixir should be for mapper configuration only; after that it should hand off to straight SQLAlchemy for normal runtime operation with any kind of Session configuration; else its just getting in the way. As I said above, it is not anymore (it used to be dependent on assign_mapper), but I changed it to support any kind of session (in version 0.3 I think). The only thing, is that we still provide a default session, which is based on Session.mapper, for convenience and backward compatibility. Maybe we should state more prominently in the Elixir doc that this is only a default session and that you can use any session you like. -- Gaëtan de Menten http://openhex.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: a way to share Session.mapper(SomeObject) across two scoped sessions?
Gaetan de Menten wrote: The only thing, is that we still provide a default session, which is based on Session.mapper, for convenience and backward compatibility. Maybe we should state more prominently in the Elixir doc that this is only a default session and that you can use any session you like. FYI, I think this should go in the advanced tutorial I referred to this morning on the Elixir list... -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: a way to share Session.mapper(SomeObject) across two scoped sessions?
On Jan 25, 2008 11:58 AM, Michael Bayer [EMAIL PROTECTED] wrote:
...so this
test will pass if you change setUp to read:
Session.mapper(SomeObject, table, properties={
'options':relation(SomeOtherObject)
}, save_on_init=False)
Session.mapper(SomeOtherObject, table2, save_on_init=False)
ah, so it does. I saw that in the code and thought I'd tried it but I
guess not. Thanks, this works.
The Session.mapper function is not worth it, in my opinion, it exists
due to the sheer popularity of its previous incarnation,
assign_mapper. I much prefer keeping things explicit.
I can understand that. I am trying to get this working for an
application that has its entire model declared in Elixir already. I
like how easy Elixir is and so I'd rather not abandon that layer.
But, there is probably a way to configure Elixir for
save_on_init=False, I will give it a go.
thanks again, Kumar
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: a way to share Session.mapper(SomeObject) across two scoped sessions?
On Jan 25, 2008, at 12:16 PM, Kumar McMillan wrote:
class ScopedMapperTest(PersistTest):
@@ -1027,6 +1046,21 @@
pass
Session.mapper(Baz, table2, extension=ext)
assert hasattr(Baz, 'query')
+
+def test_attach_assigned_objects_to_multiple_sess(self):
+PrivateSession = scoped_session(create_session,
scopefunc=lambda: '__private_session__')
+
+so1 = SomeObject()
+priv_sess = PrivateSession()
+priv_sess.save(so1)
+priv_sess.flush()
+
+so2 = SomeObject()
+sess = Session()
+sess.save(so2)
+sess.flush()
+
+PrivateSession.remove()
def test_validating_constructor(self):
s2 = SomeObject(someid=12)
the ScopedMapperTest maps the SomeObject class using the `mapper()`
function on the original Session. Therefore all SomeObject instances
are automatically saved to the Session declared in setUp(). so this
test will pass if you change setUp to read:
Session.mapper(SomeObject, table, properties={
'options':relation(SomeOtherObject)
}, save_on_init=False)
Session.mapper(SomeOtherObject, table2, save_on_init=False)
The Session.mapper function is not worth it, in my opinion, it exists
due to the sheer popularity of its previous incarnation,
assign_mapper. I much prefer keeping things explicit.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: a way to share Session.mapper(SomeObject) across two scoped sessions?
On Jan 25, 2008, at 2:02 PM, Kumar McMillan wrote:
On Jan 25, 2008 11:58 AM, Michael Bayer [EMAIL PROTECTED]
wrote:
...so this
test will pass if you change setUp to read:
Session.mapper(SomeObject, table, properties={
'options':relation(SomeOtherObject)
}, save_on_init=False)
Session.mapper(SomeOtherObject, table2, save_on_init=False)
ah, so it does. I saw that in the code and thought I'd tried it but I
guess not. Thanks, this works.
The Session.mapper function is not worth it, in my opinion, it exists
due to the sheer popularity of its previous incarnation,
assign_mapper. I much prefer keeping things explicit.
I can understand that. I am trying to get this working for an
application that has its entire model declared in Elixir already. I
like how easy Elixir is and so I'd rather not abandon that layer.
But, there is probably a way to configure Elixir for
save_on_init=False, I will give it a go.
elixir shouldn't be dependent on Session.mapper, if it is, I would
advise the elixir folks change that requirement ASAP. in my view, at
this point elixir should be for mapper configuration only; after that
it should hand off to straight SQLAlchemy for normal runtime operation
with any kind of Session configuration; else its just getting in the
way.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: a way to share Session.mapper(SomeObject) across two scoped sessions?
On Jan 24, 2008 2:46 PM, Kumar McMillan [EMAIL PROTECTED] wrote: but, since I am explicitly saving it to a new session and the session has a different scope, shouldn't this be possible? Maybe I'm not fully understanding scoped sessions. I am hesitant to file this as a bug because I'm not sure if I understand scoped sessions correctly. My understanding is that one should be able to explicitly attach the same object to different sessions as long as those sessions have different scopes. Here are two tests diffed against sqlalchemy trunk. The first one passes, as it attaches an unassigned mapped class to multiple sessions of varying scope. The second one fails with InvalidRequestError: Object '[EMAIL PROTECTED]' is already attached to session '19685424' (this is '19687888') Should I file a ticket for this? I looked at the session code briefly but wasn't sure how to fix it. Index: test/orm/session.py === --- test/orm/session.py (revision 4097) +++ test/orm/session.py (working copy) @@ -962,6 +962,25 @@ Session.remove() assert SomeObject(id=1, data=hello, options=[SomeOtherObject(someid=1)]) == Session.query(SomeObject).one() + +def test_attach_objects_to_multiple_sess(self): +Session = scoped_session(sessionmaker()) +PrivateSession = scoped_session(create_session, scopefunc=lambda: '__private_session__') + +class SomeObject(fixtures.Base):pass +mapper(SomeObject, table) + +so1 = SomeObject() +priv_sess = PrivateSession() +priv_sess.save(so1) +priv_sess.flush() + +so2 = SomeObject() +sess = Session() +sess.save(so2) +sess.flush() + +PrivateSession.remove() class ScopedMapperTest(PersistTest): @@ -1027,6 +1046,21 @@ pass Session.mapper(Baz, table2, extension=ext) assert hasattr(Baz, 'query') + +def test_attach_assigned_objects_to_multiple_sess(self): +PrivateSession = scoped_session(create_session, scopefunc=lambda: '__private_session__') + +so1 = SomeObject() +priv_sess = PrivateSession() +priv_sess.save(so1) +priv_sess.flush() + +so2 = SomeObject() +sess = Session() +sess.save(so2) +sess.flush() + +PrivateSession.remove() def test_validating_constructor(self): s2 = SomeObject(someid=12) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~--- sa_mapper_scope_tests.diff Description: Binary data
