El 21/03/17 a les 14:33, Cédric Krier ha escrit:
On 2017-03-21 13:34, Nicolas Évrard wrote:
* Sergi Almacellas Abellana [2017-03-21 12:02 +0100]:
El 20/03/17 a les 18:34, Nicolas Évrard ha escrit:
Hello,
I am currently working on two patches that will make it easier to
create python modules adding a new backend to tryton:
- https://tryton-rietveld.appspot.com/33951002/ This patch moves
the handling of the SQL type of the tryton fields to the backend.
In order to have a kind of lingua franca between tryton and the
backend we specify on the field the "abstract" SQL types it
wants to use (a M2O will use an INTEGER, a TimeDelta an
INTERVAL, and so on).
So in order to create a custom field type (I have JSONB in my mind),
we have to create a new backend? And in order to support this kind of
fields on more than one backend we have to create multiple backend?
Kind of.
The lingua franca is a just a mean so that the fields speak the same
language as the backend. It's then up to the backend to translate this
for the database.
I imagine some users having to maintain the following backends:
sqlite+spatialite
postgresql+postgis
sqlite+json
postgresql+jsonb
sqlite+spatialite+json
postgresql+postgist+json
I think that an eventual support for JSONB would be implemented using
JSONB for postgres, TEXT for sqlite and MySQL.
Having said that I'm wondering if it won't be better to allow to
register the handlers of the abstract types in external modules, so
with the same backend we will be able to handle different types of
fields, which can be then reused.
Indeed registering marshallers in the backends could be a way to
tackle the complexity of mixing together GIS and JSONB and whatnot.
Indeed what we tried to achieve is to have the backend agnostic about
fields. So we created this abstract SQL type which of course is closed
to the common SQL types.
So the design of issue6351 is to have converter on the backend using the
abstract type. Maybe we could think of a way to make those converter
extensible a little bit like what we did for json. But before that it
will be good to know how much abstract types we have and/or we could add
in the future. For example, the JSONB is not really a good abstract
type name, it should probably be an HashMap or JSON because JSONB is too
much low level.
What I miss is some mechanism to extend/modify the backend abstract
types without having to rewrite a new backend. So we can add new
abstract types directly from module and register the adapters for the
current backends. Of course and error must be throw if used with a
backend that's not aware of this abstract type.
Something like the function mapping of python-sql depending on the flavor.
But the main difficulty in introducing a new kind of abstract type which
is not common/standard is to have it supported by all backends.
And this makes me think that Tryton should not do too much in this area
as far as it allows customization of the database schema transparently.
The problem i see here is that you have to manually change the database
schema, which adds a lot of complexity when dealing with a big number of
databases or a big number of custom fields. That's why I prefer to
create a module that does it for me.
For example, the TEXT column for Dict field on postgresql should
transparently work with JSONB type.
I have tested it and it requires https://bugs.tryton.org/issue6382
--
Sergi Almacellas Abellana
www.koolpi.com
Twitter: @pokoli_srk
--
You received this message because you are subscribed to the Google Groups
"tryton-dev" group.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tryton-dev/9edf5ace-b1f6-45dd-e570-c55f8ae74774%40koolpi.com.
