Cool - Sounds like this is all figured out already :-)
I'll put this mail in my "Parking lot" along with the search
stuff, so I remember to follow up later.
Thanks,
- Ole
Alex Karasulu wrote:
Good point and actually Emmanuel and I discussed this at some point. The
idea was to have an extention to schema to disable validation for a
particular schema entity. So basically we can have a m-disable-checks
attribute in the meta.schema.
Add this to a syntax and set to TRUE and all attributes that are of that
syntax will not be checked. Also we could have a m-force-checks so you
could add this to an attribute for example that you do wnat checks on
even if it's syntax is set to disable validation.
Thgse are fine tuning configuration parameters that effect he behavoir
of the schema validation in the schema service. We definately need
some fine grained control over the way validation is performed since as
you said sometimes the apps do this automatically so why pay the price
again in the integration layer.
Alex
On 4/21/07, *Ole Ersoy* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hey Guys,
This thought may be useful for
ApacheDSs roadmap,
although it's possible we have it covered
already.
Most DAS users will want to validate
DataObjects prior to putting
them in the directory.
I'm assuming some of the processing ApacheDS
does when written to includes various
forms of validation,
upping the number of hoops the data has to jump
through before it is stored.
If it's possible to minimize this / switch it
off it will improve DAS write performance, as we
avoid duplicating the validation effort.
One thing that comes to mind wrt this are Alex's
ADS comments with respect to plugging in new Syntaxes,
and other schema elements at runtime.
Users of a "Studio" may wish to have a flag that they
flip, where the flag indicates where the validation takes place,
in ADS or the DataObject instances. However they most likely want to
know that the validation performed is "Equal". Thus it would be neat
to have an effort that creates parallel generic LDAP validators
and DataObject validators.
These would use the same core, but could have adapters that make them
suitable for use in the server or directly by a DataObject either
as an invariant or named constraints (DataObject's support XML Schema
Validation Constraints out of the box).
I need to think it through more thoroughly, but I thought I'd throw
it out there in case it's not completely whacked.
Cheers,
- Ole
