Re: [Modeling-users] three little questions

[Mario R. <ma...@ru...>]

On Lundi, d=E9c 8, 2003, at 17:45 Europe/Zurich, Sebastien Bigaret =
wrote:
> Mario Ruggier <ma...@ru...> wrote:
>> Hello,
>>
>>>> - how to best incorporate a constraint that a (non-primary, string)
>>>> attribute value should be unique ?
>>>
>>> Well, there's no way to tell the framework to enforce that, my
>>> suggestion would be to alter the db-schema to tell the database =
about
>>> this, e.g.::
>>>
>>>     ALTER TABLE BOOK ADD CONSTRAINT unique_book_title UNIQUE(TITLE);
>>
>> This seems simple enough, and would be very acceptable -- except,
>> that sqlite does not support alter table directly unfortunately, so =
it
>> becomes more messy in that case. See: =20
>> <http://www.sqlite.org/omitted.html>
>
> Right, then you need to dump the db-schema, modify it, then give it to
> sqlite. Messy, agreed. Seems to be a good reason.

Great, thanks.

>>> Note that we can maybe consider adding a 'unique' property to
>>> attributes, but then, this won't be enforced by the framework itself
>>> (because validation would require fetching all values such a field =20=

>>> and
>>> comparing) but by the database. But at least the generated db schema
>>> could take this into account, and errors would be appropriately =20
>>> raised
>>> at commit time by the database. If you really feel like you need =20
>>> this,
>>> please fill in a RFE.
>>
>> Maybe framework validation of unique need not be that expensive.
>> How about doing a raw count for 'entity where unikatt=3D"val"'? such
>> requests are superquick.
>
> You're absolutely right, sometimes I'd better think before writing :)

Or maybe, don't think too much ;)
In any case, I do not know whether doing a count will prove to be
fast enough.

>> However if you would need to do this 100's
>> of times per validation, then it will add up of course.
>> Do you have an idea whether this might be feasible?
>>
>> Even if not checked by the framework, I would be in favour of adding
>> a unique property to attributes. The priority here is to protect the =20=

>> integrity
>> of the data. If the error message received by the client is not =20
>> cryptic, then
>> so much the better.... So, I think I will fill out an RFE.
>
> We're okay on this, I'm convinced. Not sure yet whether the framework =20=

> will
> check it and leave this to the db, buit we can add such a property to
> attributes.

Great, excellent, thank you! No rush though.


>>>> - how to best handle enumeration attributes ?
>>>
>>>   I'd say, add your own validation logic for the attribute and/or =20=

>>> check
>>>   for valid values in setters.
>>
>> Hmmn. I do not like that so much (and that's not only because I'm =20
>> lazy ;).
>> This seems to be a little requested feature, so priority shuold be =20=

>> kept
>> low -- but, what do you think of an 'isEnumeration=3D[ ... ]' =
attribute =20
>> field?
>> The values inside the list must respect the type of the attribute =20
>> itself?
>> Another RFE ;-?
>
> Sorry, I don't really understand why you don't like it. This only =
means
> writing a method for checking the values, and calling it in the setter =
=20
> and in
> the validation method. Is that such a big deal?

Well, because conceptually constraints on the value of an attribute are
really part of the model. Keeping this information separate from the
model is unnatural, and may lead to "forgetfulness bugs" and other =20
annoyances.
Plus, ideally, the generated code for custom classes should be 100% =20
automatic...

But, maybe an isEnumeration property is not the best solution.
You have a description of how to add automatic handling of custom types
in the user's guide. Would this be applicable, treating an enumeration =20=

as a
special type? (Would still have the disadvantage of requiring to modify =20=

the
generated python classes... ).


>>>> - how to best handle the single quote character when writing out
>>>> string values ? (unescaped gives error for sqlite)
>>>
>>> Hmm, strange, I need to check that. This is a bug, I do not know =20
>>> whether
>>> this affects other adaptors as well --in any case you can fill in a =20=

>>> bug
>>> report for this one, thanks for reporting.
>>
>> OK, thanks.
>
> This is bug #855257 right?

Yes, it is.

> In that case, it's another bug for the qualifier
> parser, because the problem is that this string:
>
>>>> " attname =3D '%s' " %("abc'def")
> " attname =3D 'abc'def' "
>
> is a complete non-sense and should be detected as such. BTW, this =20
> reminds me
> of this RFE:
> https://sourceforge.net/tracker/=20
> index.php?func=3Ddetail&aid=3D804243&group_id=3D58935&atid=3D489338
>
>   requesting for secure quoting of qualifiers' parameters --it seems =20=

> to me
>   that both subjects are somehow connected.

Yes, they seem to be the same thing...

Generalizing, whether to single quote a value or not when constructing =20=

the SQL WHERE
clause should be detected automatically from the information in the =20
model?
Well, the mechanism we had before for building fetchSpecifications and =20=

Qualfiers
did this to some extent, or am I wrong? We should anyway not go around =20=

in circles.
The current simplicity of fetch is very nice. Just need to make =20
buildling qualifiers
easier... I use a dict that I pass to a custom function, to build the =20=

ANDed WHERE clause,
but need to generalize to OR, and other comparison operators other than =20=

equal.
In any case, the above bug is a serious problem, and would consider it =20=

high priority.

BTW, another question:
Can you express a condition such as attrib1 =3D=3D attrib2 on a given =20=

entity?


>
>         Cheers,
>
> -- S=E9bastien.
>