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. 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. For example, the TEXT column for Dict field on postgresql should transparently work with JSONB type. -- Cédric Krier - B2CK SPRL Email/Jabber: cedric.kr...@b2ck.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/ -- 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/20170321133338.GA43953%40tetsuo.
