One moe thing about the DS paths

[Emmanuel Lecharny <el...@gmail.com>]

Hi again,

currently, the default working directory for DS is server-work, not 
partitions, as defined in the InstanceLayout.

I'm all for using partitions, I find it way easier to remember, and on 
line with the current configuration.

That raises some question, too :
- should we declare the getter and setter for the 
log/conf/run/partitions paths in DirectoryService ?
- the log directory and partitions directory *must* be configurable : on 
Linux, they are likely to be move to /var/log and /var/run. How do we 
handle that ?

All these elements are well handled in the installers, we now have to 
clarify the way they are used in the server.

One small last thing : currently, indexes files are named using the 
Attribute OID. I find it not very friendly. Can't we use the Alias instead ?

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: One moe thing about the DS paths

[Kiran Ayyagari <ka...@apache.org>]

On 10/28/10, Emmanuel Lecharny <el...@gmail.com> wrote:
> On 10/28/10 9:55 AM, Kiran Ayyagari wrote:
>>
>>>> One small last thing : currently, indexes files are named using the
>>>> Attribute OID. I find it not very friendly. Can't we use the Alias
>>>> instead
>>>> ?
>> -1, there is a reason we changed back to OID, it is to avoid creating
>> duplicate indexes
>> on the same AT.
>>
>> If we use alias then there is no way to check them,
>> e.x if user creates two indexes on "cn" and "commonName" then jdbm
>> creates "cn.db" and "commonName.db" which we cannot distinguish during
>> creation
> We can check that using the SchemaManager, which is available when we
> create the files. AT.getName() always return the first alias.
we can't depend on this as the schema *might* change(e.x a custom
schema) the order of aliases.
Checking for the existing indexes requires to get
all the *.db files and perform various checks on
their names (after removing ".db") but this check needs to be
performed after *every* single index
instantiation

>> Another case is to find which indexes are no longer needed when user
>> removes them from config.
> Same, using the SM will do the trick.
>> We store a OID.txt file with AT's definition alongside the index files
>> to let the user know what that indexed attribute is.
> Do we? Never saw this file.
yes, we create them
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>


-- 
Kiran Ayyagari

Re: One moe thing about the DS paths

[Emmanuel Lecharny <el...@gmail.com>]

On 10/28/10 9:55 AM, Kiran Ayyagari wrote:
>
>>> One small last thing : currently, indexes files are named using the
>>> Attribute OID. I find it not very friendly. Can't we use the Alias instead
>>> ?
> -1, there is a reason we changed back to OID, it is to avoid creating
> duplicate indexes
> on the same AT.
>
> If we use alias then there is no way to check them,
> e.x if user creates two indexes on "cn" and "commonName" then jdbm
> creates "cn.db" and "commonName.db" which we cannot distinguish during
> creation
We can check that using the SchemaManager, which is available when we 
create the files. AT.getName() always return the first alias.
> Another case is to find which indexes are no longer needed when user
> removes them from config.
Same, using the SM will do the trick.
> We store a OID.txt file with AT's definition alongside the index files
> to let the user know what that indexed attribute is.
Do we? Never saw this file.

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: One moe thing about the DS paths

[Kiran Ayyagari <ka...@apache.org>]

On 10/28/10, Pierre-Arnaud Marcelot <pa...@marcelot.net> wrote:
> Hi Emmanuel,
>
> On 28 oct. 2010, at 02:39, Emmanuel Lecharny wrote:
>
>> Hi again,
>>
>> currently, the default working directory for DS is server-work, not
>> partitions, as defined in the InstanceLayout.
>>
>> I'm all for using partitions, I find it way easier to remember, and on
>> line with the current configuration.
>>
>> That raises some question, too :
>> - should we declare the getter and setter for the log/conf/run/partitions
>> paths in DirectoryService ?
>
> -1, I think we should pass an InstanceLayout object instead and that object
> could be shared between configuration objects.
I agree with Pierre-Arnaud, let us not tie the InstanceLayout to DS,
it is just a kind of semantic we follow or set for making
installations follow a standard path
otherwise all that we need to start a DS is just a plain path to a folder.
>
>> - the log directory and partitions directory *must* be configurable : on
>> Linux, they are likely to be move to /var/log and /var/run. How do we
>> handle that ?
>
> I'm not sure, I handled that correctly in the Linux installers (has to be
> checked).
> AFAIR, it's possible to override the default ([InstallationLayout]/log] path
> with the use of System properties defined when launching the server like
> "-Dapacheds.log.dir" and others.
yeah, a better option is to tell the user(or ask him to choose during
installation) to symlink
the directories present under the InstanceLayout, then it won't break
our program
ex. we want to find the pid of the server and getRunDir() will return
the linked /var/run
>
>> All these elements are well handled in the installers, we now have to
>> clarify the way they are used in the server.
yeap they are and personally am perfectly happy with them
>
> As I said, it will probably need to be double-checked in the installers.
>
>> One small last thing : currently, indexes files are named using the
>> Attribute OID. I find it not very friendly. Can't we use the Alias instead
>> ?
-1, there is a reason we changed back to OID, it is to avoid creating
duplicate indexes
on the same AT.

If we use alias then there is no way to check them,
e.x if user creates two indexes on "cn" and "commonName" then jdbm
creates "cn.db" and "commonName.db" which we cannot distinguish during
creation

Another case is to find which indexes are no longer needed when user
removes them from config.

We store a OID.txt file with AT's definition alongside the index files
to let the user know what that indexed attribute is.

Though the above examples are applicable for JDBM based partition,
they all still hold good
for all types of partition implementations.

>
> +1, or the OID if the AT has no aliases.
this helps, but let us have a unique naming convention

Kiran Ayyagari

Re: One moe thing about the DS paths

[Pierre-Arnaud Marcelot <pa...@marcelot.net>]

On 28 oct. 2010, at 11:16, Emmanuel Lecharny wrote:

> On 10/28/10 9:30 AM, Pierre-Arnaud Marcelot wrote:
>> Hi Emmanuel,
>> 
>> On 28 oct. 2010, at 02:39, Emmanuel Lecharny wrote:
>> 
>>> Hi again,
>>> 
>>> currently, the default working directory for DS is server-work, not partitions, as defined in the InstanceLayout.
>>> 
>>> I'm all for using partitions, I find it way easier to remember, and on line with the current configuration.
>>> 
>>> That raises some question, too :
>>> - should we declare the getter and setter for the log/conf/run/partitions paths in DirectoryService ?
>> -1, I think we should pass an InstanceLayout object instead and that object could be shared between configuration objects.
> Problem is : this class is not visible from the configuration. It has to be moved to another project then. To be discussed.

Not really an issue.
+1 on the move.

>>> - the log directory and partitions directory *must* be configurable : on Linux, they are likely to be move to /var/log and /var/run. How do we handle that ?
>> I'm not sure, I handled that correctly in the Linux installers (has to be checked).
>> AFAIR, it's possible to override the default ([InstallationLayout]/log] path with the use of System properties defined when launching the server like "-Dapacheds.log.dir" and others.
> I know, it's just that we have to allow the user of the embeded version to do the same.

+1 we could have a specific setter for each directory in the installation. You could use it to override the default value ([Instance directory]/specific directory).

>>> All these elements are well handled in the installers, we now have to clarify the way they are used in the server.
>> As I said, it will probably need to be double-checked in the installers.
> Installers are OK. It's the embedded server which is an issue.

I'm not sure we're currently logging into /var/log on linux actually.

Regards,
Pierre-Arnaud

Re: One moe thing about the DS paths

[Emmanuel Lecharny <el...@gmail.com>]

On 10/28/10 9:30 AM, Pierre-Arnaud Marcelot wrote:
> Hi Emmanuel,
>
> On 28 oct. 2010, at 02:39, Emmanuel Lecharny wrote:
>
>> Hi again,
>>
>> currently, the default working directory for DS is server-work, not partitions, as defined in the InstanceLayout.
>>
>> I'm all for using partitions, I find it way easier to remember, and on line with the current configuration.
>>
>> That raises some question, too :
>> - should we declare the getter and setter for the log/conf/run/partitions paths in DirectoryService ?
> -1, I think we should pass an InstanceLayout object instead and that object could be shared between configuration objects.

Problem is : this class is not visible from the configuration. It has to 
be moved to another project then. To be discussed.
>> - the log directory and partitions directory *must* be configurable : on Linux, they are likely to be move to /var/log and /var/run. How do we handle that ?
> I'm not sure, I handled that correctly in the Linux installers (has to be checked).
> AFAIR, it's possible to override the default ([InstallationLayout]/log] path with the use of System properties defined when launching the server like "-Dapacheds.log.dir" and others.
I know, it's just that we have to allow the user of the embeded version 
to do the same.
>> All these elements are well handled in the installers, we now have to clarify the way they are used in the server.
> As I said, it will probably need to be double-checked in the installers.
Installers are OK. It's the embedded server which is an issue.

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: One moe thing about the DS paths

[Pierre-Arnaud Marcelot <pa...@marcelot.net>]

Hi Emmanuel,

On 28 oct. 2010, at 02:39, Emmanuel Lecharny wrote:

> Hi again,
> 
> currently, the default working directory for DS is server-work, not partitions, as defined in the InstanceLayout.
> 
> I'm all for using partitions, I find it way easier to remember, and on line with the current configuration.
> 
> That raises some question, too :
> - should we declare the getter and setter for the log/conf/run/partitions paths in DirectoryService ?

-1, I think we should pass an InstanceLayout object instead and that object could be shared between configuration objects.

> - the log directory and partitions directory *must* be configurable : on Linux, they are likely to be move to /var/log and /var/run. How do we handle that ?

I'm not sure, I handled that correctly in the Linux installers (has to be checked).
AFAIR, it's possible to override the default ([InstallationLayout]/log] path with the use of System properties defined when launching the server like "-Dapacheds.log.dir" and others.

> All these elements are well handled in the installers, we now have to clarify the way they are used in the server.

As I said, it will probably need to be double-checked in the installers.

> One small last thing : currently, indexes files are named using the Attribute OID. I find it not very friendly. Can't we use the Alias instead ?

+1, or the OID if the AT has no aliases.

Regards,
Pierre-Arnaud