Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 27 Jun 2013 14:12:00 +0200] rev 9113
[repository] add an ``internal_cnx`` method to replace ``internal_session``
Accessing the repo through a Session is deprecated. We need an easy replacement
for ``internal_session``.
This API change was a good occasion to stop disabling integrity hook by default.
This is huge source of bug in user-code.
related to #2503918
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 27 Jun 2013 12:02:38 +0200] rev 9112
[connection] enforce that a connection must be open to be used
The same than for ClientConnection, we ensure the connection is used inside a
its context.
.. note:: We may rely on that for ClientConnection and remove de dedicated code
in Client Connection but I prefer the current explicite and duplicated
version for now.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 26 Jun 2013 15:11:22 +0200] rev 9111
use standalone Connection to Client Connection
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 26 Jun 2013 14:46:24 +0200] rev 9110
[session] add a new_cnx factory
Having user-code importing cubicweb.server.session.Connection is inconvenient.
We add a simple factory fonction on the session.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 26 Jun 2013 14:26:06 +0200] rev 9109
[connection] allow simple instantiation of standalone Connection
Such connection will automatically pick a connection id. Note, They are not
automatically closed on session close. But they will fails to grab new cnxset
once the session is closed.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 26 Jun 2013 14:35:55 +0200] rev 9108
[connection] handle and explicitly life cycle on Connection
Like ClientConnection, Connection object need to be explicitly started and stop.
They aims to be used as context manager.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 26 Jun 2013 14:00:32 +0200] rev 9107
[sesion] distinction between Connection handled by the session and other.
Not mixing the new and backward compat approach seems a good idea. Let's enforce
it.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 26 Jun 2013 11:58:34 +0200] rev 9106
[session] replace _clear_thread_storage with close_cnx
There is not good reason to keep two distinct method.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 26 Jun 2013 14:01:07 +0200] rev 9105
[session] explicitly take Connection object in close_cnx
Now that ClientConnection explicitly reference and use the Connection object we
do not need to use connectionid here.
We can safely change this signature, ClientConnection is the only use of
close_cnx for now.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 26 Jun 2013 11:41:53 +0200] rev 9104
[session] drop the Session._clear_cnx_storage method
It is just cnx.clear() now.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 26 Jun 2013 11:39:41 +0200] rev 9103
[session] wrap too long line
Too long line is too long.
(Confucius 503 BC)
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 26 Jun 2013 11:39:01 +0200] rev 9102
[session] gather close_cnx with get_cnx and set_cnx
They do the same kind of operation and deserve to be grouped together.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 27 Jun 2013 11:13:18 +0200] rev 9101
[client-connection] remove the _srv_cnx usage
It does not do anything special now that we use explicite Connection object with
automatic cnx_set handling.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 27 Jun 2013 11:04:31 +0200] rev 9100
[client-connection] explicitly check that the client-connection is open
The check is also perform by the _srv_cnx property. But we do not need those
property anymore.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 27 Jun 2013 11:02:30 +0200] rev 9099
[client-connection] handle the lack of connection id while not open
the connection id is computed at opening and forgotten when closing. We can't
rely on it in various messages … like the "connection closed" exception.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 26 Jun 2013 11:21:39 +0200] rev 9098
[connection] transparent cnx_set handling
Connection object while take cares of there cnxset themself (as dbapi connection
does).
The ``set_cnxset`` and ``free_cnxset`` operation are still available for
backward compatibility purpose. The ``_auto_free_cnx_set`` is introduced to
handle mixed usage.
A new context manager ``connection.ensure_cnx_set`` is added for code that
access ``cnx.cnxset`` directly and are not wrapped in any specific
``Connection`` method.
A ``_with_cnx_set`` decorator is used on all Connection method that need a
cnxset.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 27 Jun 2013 10:44:40 +0200] rev 9097
[client-connection] explicit the client part in __repr__
Now that we have real server side connection we need to remove ambiguity.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 25 Jun 2013 19:50:16 +0200] rev 9096
[ClientConnection] directly use the Connection object to access the database
Now that Connection are a full featured standalone object we can directly
reference and use it in the ClientConnection instead of using the session.
The session object is kept around for a while to perform various utility role.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 25 Jun 2013 18:15:45 +0200] rev 9095
[connection] invert __init__ parameter
Takes session first. At some point, the connection_id will become optional for Connection
created explicitly.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 26 Jun 2013 13:43:22 +0200] rev 9094
[service] enforce that Service argument and return are json-serialisable
The call_service API need to be able to run through RPC. So we ensure front
start that it is possible serialise both input and output.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 25 Jun 2013 18:04:08 +0200] rev 9093
[connection] move call_service on Connection
This is the last step toward standalone transaction.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 27 Jun 2013 11:21:14 +0200] rev 9092
[connection] move the commit method on Connection object
One step closer of standalone Connection!
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 27 Jun 2013 11:21:09 +0200] rev 9091
[connection] move the rollback method on Connection object
One step closer of standalon Connection.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 27 Jun 2013 11:20:46 +0200] rev 9090
[connection] pass a Connection object to RQLRewriter
RQLRewriter can now directly use a Connection object. No need for specific
handling session side.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 27 Jun 2013 11:20:14 +0200] rev 9089
[connection] Connection.execute touch Session timestamp
This allow to keep Session alive while using Connection object only for database
access.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 25 Jun 2013 17:42:12 +0200] rev 9088
[connection] Connection now call _set_user to CWUser object linked to itseld
Session.user is linked to the session.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 25 Jun 2013 14:13:50 +0200] rev 9087
[server/session] better faking of user for InternalManager
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 27 Jun 2013 11:19:58 +0200] rev 9086
[connection] move execute
All necessary method are now available on the Connection object. So the
Connection can handle RQL execution itself.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 25 Jun 2013 17:10:52 +0200] rev 9085
[connection] mark Connection as "not a request"
The ORM use this information. Having a wrong value will lead to crash.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 25 Jun 2013 14:04:46 +0200] rev 9084
[server/session] ensure appobject obtained from the session are linked to the session
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 25 Jun 2013 12:25:52 +0200] rev 9083
[connection] have rql_rewriter accession on Connection
Code expecting a session search the RQLRewriter on this attribute.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 27 Jun 2013 11:19:42 +0200] rev 9082
[connection] move local_perm_cache management on Connection
It belongs here anyway.