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. > (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' ? > 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. -- Pierre-Louis
