Pierre van Rooden wrote:
I am reworking fields and datatypes so that you can redefine a field
by describing it's datatype instead of using the <db> tag.
This should be in a next release - the old way will still work,
ofcourse, but it is an additional option that is primarily ment to
make builder xmls cleaner.
The idea is that you can specify a field as follows:
<field name="mydata">
<datatype base="eline" xmlns="http://www.mmbase.org/xmlns/datatypes"; >
<required value="true" />
<maxlength value="255" />
</datatype>
</field>
Which would automatically deduce type (STRING), size (255), state
(persistent) and notrnull (true, dependent on required).
You van override state and readionly status as field tag attributes:
<field name="generatedinfo" state="virual" readonly="true">
...
and override type, size, and notnull using the <storage> tag:
<field name="mydata2">
<datatype base="xml" xmlns="http://www.mmbase.org/xmlns/datatypes"; >
<maxlength value="255" />
</datatype>
<storage type="STRING" size="1024" notnull="true" >
</field>
(the example may not make much sense, but there could be situations
where this is needed.
I didn't want to use the db.type tag, as it has a lot of other stuff.
So I added a storage key that overrides a datatype's default (or
defines the datatype if you do not define it).
Anyway, when working on trying to determine size using a
LengthDatatYpe maxLength propery I found this:
- Field.getMaxLenth() is an int
- LengthDataType.getMAxLength() is a long
Both are (as of 1.8) part of the bridge.
This means that to solve the conflict between the two is hard to do
without breaking backward compatibility in the bridge.
I was wodnetring what should be done?
I now downsize the long to int, which works for the 1.8 release, but
should we change the type of either method?
And if so, when? In 1.9? Or asap?
I don't care when.
What disturbs me is that there are already plans to introduce migration
issues from 1.8 to 1.9 even before the 1.8 release is secured in a branch.
I already spend a lot of time to convert builders from the old 1.7 to
the 1.8 format. Builder files are one of those things which should be
stable, because everyone must use them. Changing them every release will
make it much more difficult to upgrade. Do we really need a new version
again? If the sole argument is to make it more cleaner then I think my
argument outweights that. When there are other argument then put them in
a document so we can discuss it before implementing it.
Regards,
Nico
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
