Sql-constraint on Char: allow empty values or make Char default to NULL

Support Developer
1

Mittelab’s implementation of “association” (see Association blueprint) has I minor issue, I try to solve: One can not have two Members in “draft” state. This is caused by the fact that when saving a Member, it will get code “” (empty string) - anyhow code is defined as “unique”. This inhibits saving a second Member in “draft” state.

How can I make “code” to be NULL instead of an empty string by default? Or is there any other solution?

This is the relevant part of Member, defining code: complete code

class Member(…):
    …
    code = fields.Char("Code", select=True,
        states={
            'readonly': Eval('code_readonly', True),
            'required': Eval('state') != 'draft'
            },
        depends=_depends + ['code_readonly'],
        help="The internal identifier for the associate.")
    code_readonly = fields.Function(fields.Boolean("Code Readonly"),
                                    'get_code_readonly')
    @classmethod
    def __setup__(cls):
        …
        cls._sql_constraints = [
            ('code_uniq',
              Unique(t, t.code),
              'association.msg_member_code_unique'
            ),
        ]

@wifasoi

2

As there is no technical reason to have a unique constraint on the code field, I realy would avoid it. Even the invoice number has no such a constraint, as it is driven by an ir.sequence. An alternative approach would be using ModelStorage.validate there you can use an informative error message with additional information which number is already used, to ease the detection of possible double entries.

3

Thanks for you quick resonce, lat in the evening :slight_smile:

Member.code might not be backed by a sequence: In the Menbership configuration, one can easily remove the “member sequence”, which will make the code field read/write. (This seems to modeled be like Article.code .

4

Yes, but the unique code constraint on products in Tryton was especially introduced, to be able to use the code as identifier for SKU. Membership numbers IMHO should not have such a hard requirement on uniqueness. What speaks against having two members with the same code, when a warning was shown that it already exists? In the past in many places in Tryton we remove SQL-constraints when there is not technical reason, because they break the modularity.

5

Just use an Exclude constraint with the proper clause to not check draft state.

6

Ok, seams reasonable.
I can it and push it in codereview (or @htgoebel ou can email a patchset if you want).

Anyway, I’m not dead… just a bit too busy :smiley:

7

@ced Thanks pointing to Exclude. So you recommend keeping the SQL-constraints?

8

@wifasoi Patchset is available at htgoebel/trytond-association: Fork and extension of of https://git.mittelab.org/infra/tryton/mittelab_association - trytond-association - Codeberg.org