A Dimarts, 27 de setembre de 2011 09:33:37, Cédric Krier va escriure:
> On 27/09/11 08:24 +0200, Albert Cervera i Areny wrote:
> > AFAIK properties currently only allow Many2One values
> 
> No, it also manage Numeric, Char and Selection. But it should be improved
> to manage also other fields.
> 
> > and they use Reference
> > fields to point to the records which are somewhat slower to process and
> > most important do not use referential integrity features of the
> > underlying DBMS.
> 
> The referential integrity is managed on reading as there was an "ON DELETE
> SET NULL" and this is for all the Reference fields.
> But we should probably add also the management of ondelete in ModelSQL as
> it is done for the Many2One fields.
> > I
> > think properties could be changed to use a One2Many() field underneath
> > and automatically create a new model to store their information.
> > 
> > For example, the following code:
> >     customer_payment_term = fields.Property(fields.Many2One(
> >     
> >               'account.invoice.payment_term', string='Customer Payment
> >               Term'))
> > 
> > Could automatically create a new model equivalent to:
> > 
> > class party.party.customer_payment_term(ModelSQL):
> >     party = fields.Many2One('party.party),
> >     payment_term = fields.Many2One('account.invoice.payment_term'),
> > 
> > or could be expected the developer to create it manually.
> > 
> > This would had the advantage of using referential integrity and support
> > all field types out of the box. It may also mean improved performance as
> > well as creating a more intuitive database structure for those who need
> > to extract information from the database.
> 
> But how do you manage default values?

Is there a need for default values? I mean, why should there be default values 
for a field that depends on the company but not for other fields? That said, 
default values could be set by letting company field to be NULL (see below). It 
may require an explicit configuration section, but mabe that is more "Trytonic" 
than existing behaviour?

> And also I don't see how the behavior of the Property fields could be
> changed as it is now for multi-company.

Forgot to add it in the model, of course, a Property would have no sense 
without a Company:

class party.party.customer_payment_term(ModelSQL):
     party = fields.Many2One('party.party)
     payment_term = fields.Many2One('account.invoice.payment_term')
     company = fields.Many2One('company.company')

One could also think of extending existing Properties to handle something like 
this:

field_name = fields.Property('company.department', fields.Many2One(....))

so one could make properties depend on other "things" apart from the company.

-- 
Albert Cervera i Areny
http://www.NaN-tic.com
Tel: +34 93 553 18 03

http://twitter.com/albertnan 
http://www.nan-tic.com/blog

-- 
[email protected] mailing list

Reply via email to