Re: [Modeling-users] three little questions

[Sebastien B. <sbi...@us...>]

        Hi,

Mario Ruggier <ma...@ru...> wrote:
> Hello,
>=20
> >> - 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);
>=20
> 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: <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.

> > 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 and
> > comparing) but by the database. But at least the generated db schema
> > could take this into account, and errors would be appropriately raised
> > at commit time by the database. If you really feel like you need this,
> > please fill in a RFE.
>=20
> Maybe framework navigation of unique need not be that expensive.
> How about doing a raw count for 'entity where unikatt=3D"val"'? such
> requests are superquick.=20

You're absolutely right, sometimes I'd better think before writing :)

> 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?
>=20
> 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 inte=
grity
> of the data. If the error message received by the client is not 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 will
check it and leave this to the db, buit we can add such a property to
attributes.

>=20
> >> - how to best handle enumeration attributes ?
> >
> >   I'd say, add your own validation logic for the attribute and/or check
> >   for valid values in setters.
>=20
> Hmmn. I do not like that so much (and that's not only because I'm lazy ;).
> This seems to be a little requested feature, so priority shuold be kept
> low -- but, what do you think of an 'isEnumeration=3D[ ... ]' attribute f=
ield?
> The values inside the list must respect the type of the attribute 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 and =
in
the validation method. Is that such a big deal?

> >> - 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 whether
> > this affects other adaptors as well --in any case you can fill in a bug
> > report for this one, thanks for reporting.
>=20
> OK, thanks.

This is bug #855257 right? 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 reminds me
of this RFE:
https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D804243&group_=
id=3D58935&atid=3D489338

  requesting for secure quoting of qualifiers' parameters --it seems to me
  that both subjects are somehow connected.

        Cheers,

-- S=E9bastien.