directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot ...@marcelot.net>
Subject Re: Apache Studio ldif export
Date Fri, 23 Jan 2009 10:28:43 GMT
Hi Cheong Chung Onn,

On Fri, Jan 23, 2009 at 3:05 AM, Cheong Chung Onn
<chungonn@greenfossil.com>wrote:

> Hi Pierre-Arnaud,
>
> Yes, I created a new partition without any index attributes. I too am
> lazy.. :)


Then, I'm not the only one. ;)

I think it would be better to provide a minimum set of indices when creating
a new partition.
Same thing for the other fields.
Having default values for all fields would help a lot I think.

Here's  my  2 cents worth about -  should Client or Server side do the
> ordering.
>
> 1. If the Studio or Client side would to do the  ordering, that would mean
> all clients must implement the same piece of logic over and over again. That
> may cause future support issues.
>
> 2. If the Server side do the ordering then what happen if Studio is used
> against other Ldap Servers that does not order an exported entries?
>
> For me now, it does not matter whether  Client or Server do the ordering,
> because the only tool i now use  for Ldap development is Apache DS and
> Studio and sometimes OpenLdap to confirm my  development works on it too.


It's really nice to hear that. Looks like the couple Apache Directory Server
and Apache Directory Studio is doing a great job in your development
environement. Do not hesitate to give us feedback on how we can improve
both.

Actually, we fixed the problem by reordering the ldif entries ourselves
> manually. I thought it would be cool if Studio Ldif Editor has a feature to
> re-order the ldif hierarchy.


You could also fix it by providing indices to your partition. It would be
better than having to re-order the exported LDIF afterwards.
But, your proposal for a re-order command is a good idea. You should propose
this as a Jira.
Maybe we can find some time to implement it.

Best regards,
Pierre-Arnaud

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message