On 26/05/2015 14:35, Nicolas Évrard wrote: > * Pierre-Louis Bonicoli [2015-05-26 13:58 +0200]: >> On 26/05/2015 09:19, Nicolas Évrard wrote: >>> * Pierre-Louis Bonicoli [2015-05-26 02:33 +0200]: >>>> On 26/05/2015 00:55, Cédric Krier wrote: >>>>> On 25 May 18:00, Pierre-Louis Bonicoli wrote: >>>>>> On 21/05/2015 17:52, Cédric Krier wrote: >>>>>>> I'm facing a limitation with how trytond generate the table name >>>>>>> for a >>>>>>> ModelSQL. Databases have different length limitation for schema >>>>>>> name. >>>>>>> For example, >>>>>>> PostgreSQL has the limit to 64 when Oracle has the limit to 30 >>>>>>> (yes I'm working on an Oracle backend). >>>>>>> >>>>>>> I don't want that we change our naming convention because it is >>>>>>> quite >>>>>>> good and reducing the name will just bring a lot in readability. >>>>>>> And we will be forced to use the least common constraint. >>>>>>> >>>>>>> So my idea is to have a configuration section which will provide the >>>>>>> table name to use for a Model. >>>>>>> >>>>>>> Example: >>>>>>> >>>>>>> [table] >>>>>>> account.invoice.payment_term.line.relativedelta = >>>>>>> acc_inv_pt_l_reldelta >>>>>>> account.payment.sepa.message = acc_payment_sepa_msg >>>>>>> >>>>>>> Of course such configuration could not be modified once a >>>>>>> database has >>>>>>> been created (or the table should be renamed). >>>>>>> >>>>>>> Side effect, it could also be used to fix naming conflict between 2 >>>>>>> unrelated module (at the database level not Model.__name__). >>>>>>> >>>>>>> What do you think? >>>>>> >>>>>> The names of the tables should be identical for two installations >>>>>> using >>>>>> the same backend. A module should not require this kind of >>>>>> configuration. >>>>>> >>>>>> Could not we delegate the transformation of a model name into a table >>>>>> name to the backends with something like that: >>>>>> 'cls._table = backend.TableHandler.name(cls.__name__)' ? >>>>> >>>>> OK but what is your proposal on how such method will always create >>>>> valid >>>>> table name. >>>> >>>> We keep the current behavior (dots replaced by underscore) and use the >>>> same approach as django (last X characters replaced by >>>> 'hash(name)[:X]'). >>> >>> Isn't this better: >>> >>> hash = str(hash(old_name)) >>> new_name = old_name[:maximum_length - len(hash)] + hash >>> >> >> What hash function would you like to use ? Django uses a value of 4 >> for X, we could use a greater value. > > Any good hash function that will return the same result across python > versions. But as I said this idea comes with its drawbacks so I don't > think we should implement it. > >>> (It is probably better to use an hexadecimal representation of the >>> hash in order to reduce its length). >>> >>> But it is still possible to create a table that will collide with >>> another whose name is too long (unless we transform every table with >>> this function but it is not a desirable behavior according to me). >> >> You mean that collision is still possible using a model name like >> 'account.invoice.paymen97171639' ? > > Yes. >
Model name using numbers only from twenty-third to thirtieth characters could be considered as invalid. >>> I find this idea quite elegant (because there is no need for the >>> configuration file) but the names generated will be strange and not >>> meaningful. >>> >>> So for the sake of interoperability with other systems I still prefer >>> the mapping solution (although it's an ugly one and I would welcome a >>> better idea). >> >> If the chosen solution is the mapping one, the documentation (core and >> each module) should list the names of the tables. > > Why should it? How will an administrator know that the table used by the model 'account.invoice.payment_term.line.relativedelta' should be mapped ? Before a new module installation, knowing only the name of a table which should be mapped, how will an administrator know the names of the other tables used by this module - the names he can not use with the mapping ? > If it's up to the administrators of the tryton server to decide which > name a table should have through configuration why should we add this > information in the documentation? We might as well define the name of > the tables in the objects if this information is static. > > But of course the mapping defined in the configuration has to be known > by people using other systems to access the data. But this is up to > the people implementing their ERP to provide this information. -- Pierre-Louis
