directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole.er...@gmail.com>
Subject Re: [DAS] Type's ObjectClass Entry
Date Sun, 22 Apr 2007 16:38:33 GMT
Hi Emmanuel and Stefan,

Stefan Seelmann wrote:
> Hi Ole,
> 
> as Emmanuel I would recommend to create objectClasses and attributeTypes
> for each user defined class.

Yes we are doing that.

> Do you already have a plan how to store references between objects in
> LDAP? 

I have one plan, but Emmanuel and yourself are goooddd, so I'll
gladly here more.

> There are different strategies.
> 
> For example you could use distinguished names to implement references.
> 
> Say, there are two POJOs Employee and Department:
> ----------------------------------------
> class Employee
> {
>   String firstName;
>   String lastName;
>   Department department;
> }
> 
> class Department
> {
>   String departmentName
>   List<Employee> employees;
> }
> ----------------------------------------
> 
> Then two concrete objects could be stored like that in LDAP:
> ----------------------------------------
> cn=12345678,ou=Employee,ou=das,dc=example,dc=com
> cn: 12345678
> givenName: John
> sn: Doe
> department: cn=23456789,ou=Department,ou=das,dc=example,dc=com
> 
> cn=23456789,ou=Department,ou=das,dc=example,dc=com
> cn: 23456789
> departmentName: Development
> employee: cn=12345678,ou=Employee,ou=das,dc=example,dc=com
> employee: cn=12345679,ou=Employee,ou=das,dc=example,dc=com
> employee: cn=12345680,ou=Employee,ou=das,dc=example,dc=com
> employee: .....
> ----------------------------------------
> 
> That is just one alternative. But it is really important to design this
> properly. I think Alex and David Jencks discussed such strategies some
> time ago.

Yes this is precisely how we are doing it.  Great to know we are all on
the same page.


============
WRITE OPERATION
============

The part where I need the additional "metaObjectClass"
is during the writing and restoration of
metadata.

So before the DAS writes DataObject instances
it writes each instances Type, corresponding a ObjectClass
entry in the DAS's schema area.

So Employee would have a unique ObjectClass and
Department would have a unique ObjectClass.

Then once these are written, it starts to write
the DataObject instances as you showed above.

============
READ OPERATION
============

Then upon a restore of a DataGraph, the first
thing the DAS does is restore the Type system.

This includes all user defined types like Employee
and Department.

When restoring Employee it creates
EAttributes (Which are models of simple xsd properties
corresponding to AttributeType entries)
and EReferences which are models of complex xsd properties
that have a corresponding ObjectClass entry.

For example when the DAS restores the
the Employee type it would do something like this:

EClass eClass   = EcoreFactory.eINSTANCE.createEClass("Employee");

EAttribute firstName EcoreFactory.eINSTANCE.createEAttribute("firstName");
...
EReference department = 
EcoreFactory.eINSTANCE.createEReference("department");
....
eClass.getEAttributes().add(firstName);
eClass.getEReferences().add(department);
..............

Now it can create an instance of an employee
like this:

EObject employee = EmployeeFactory.eINSTANCE.create("Employee");
Then it starts restoring the employee state using the
employee's entry.

So during this Type restore process,
it gets the EAttribute instances it needs
to create from the
com.example.Employee ObjectClass's "m-may" and "m-must"
attributes, which would be named:

com-example-Employee-firstName
com-example-Employee-lastName

And it would get the "department"
EReference (named com-example-Employee-department)
name from the "m-complexMay"
attribute if an instance of the EReference
is required, and "m-complexMust" attribute
otherwise.

Does that make sense?

Thanks,
- Ole

Mime
View raw message