You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Ole Ersoy <ol...@gmail.com> on 2007/04/22 02:12:31 UTC
[DAS] Write Performance
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
Re: [DAS] Write Performance
Posted by Ole Ersoy <ol...@gmail.com>.
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* <ole.ersoy@gmail.com
> <ma...@gmail.com>> 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
>
>
>
>
>
Re: [DAS] Write Performance
Posted by Alex Karasulu <ak...@apache.org>.
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 <ol...@gmail.com> 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
>
>
>
>
>