[Cosmo-dev] Discussion of hibernate data model

[Charles Mattair]

Some traffic has be going on outside the list.  I'm digestifying this and posting it
to the list.  Future traffic will be off this tread.

cgm

28 jul 15:35

Brian,

Charles and I have been thinking about what the best way to go about re-factoring this data model stuff is.  We have a few questions.  By the way, we figured some of these questions are pretty specific to the code so we didn't copy to the list.

Going through the code, we were trying to figure out what the object model defined in org.osaf.cosmo.model is used for.  It looks like these objects are mainly used by the cosmo ui.  Is that correct?  As far as I could tell, the caldav classes (that extend from the jcr-server classes) operate on JCR nodes directly, instead of a "Calendar" or "Event" objects.   What do you think about using this object model for the new service apis?

In the data model we are proposing, the JCR node would be replaced with the notion of a resource, or as you suggested "item".  We like the term "resource" because that is what the current code uses and that is what the underlying dav model implies.  Instead of exposing the core "resource" or "item" objects, we would expose subclasses such as "Calendar" and "Event" that would derive from the underlying class.
We have prototyped a first approximation of a database schema  (and hibernate mapping files/classes) that pretty closely mirrors the JCR model.  We have done some initial sanity tests to validate performance (shoving 250K events and 1.75M properties into a MySQL db and performing basic queries) and we are in the ballpark.  We are ready to define an object model and service apis that will be surfaced in the cosmo world.

So then comes the question of what services we need to expose.  It looks like we need to provide new implementations of UserService and HomeDirectoryService (or maybe just the daos), and then provide a number of services for calendar and dav object access.  These would be the services that you would use when re-writing the jcr-server component.  Speaking of which, how do you want to coordinate this?  We can start pretty soon on these services, so what would be the best way to collobarate?  We could give you the api interfaces and then you could start coding the jcr-server based on these(letting us know what changes to the api you need). Suggestions?

Also, if you think of any Chandler requirements outside of a dav/caldav model, let us know so we can make sure there will be some way to support them.

-Randy and Charles

31 jul 12:26

On 7/28/06, rletness at simdeskcorp.com <rletness at simdeskcorp.com> wrote:

 > Brian,
 >
 > Charles and I have been thinking about what the best way to go about
 > re-factoring this data model stuff is.  We have a few questions.  By the
 > way, we figured some of these questions are pretty specific to the code
 > so we didn't copy to the list.


i think the osaf community folks would prefer everything to go to the
list. their aim is complete transparency.

 > Going through the code, we were trying to figure out what the object
 > model defined in org.osaf.cosmo.model is used for.  It looks like these
 > objects are mainly used by the cosmo ui.  Is that correct?  As far as I
 > could tell, the caldav classes (that extend from the jcr-server classes)
 > operate on JCR nodes directly, instead of a "Calendar" or "Event"
 > objects.   What do you think about using this object model for the new
 > service apis?


you're right - the jcr-server classes use jcr directly, whereas the
rest of the server goes through the cosmo service apis. that's the
purpose of my jcr-server project - to re-implement those interfaces
using the cosmo service apis. so yeah, we should be using/updating the
existing model classes as necessary.

 > In the data model we are proposing, the JCR node would be replaced with
 > the notion of a resource, or as you suggested "item".  We like the term
 > "resource" because that is what the current code uses and that is what
 > the underlying dav model implies.  Instead of exposing the core
 > "resource" or "item" objects, we would expose subclasses such as
 > "Calendar" and "Event" that would derive from the underlying class.


i'd really like to use "item". one of my goals for this project (and
for upcoming chandler/cosmo sharing work) is to remove the dav-isms
from the data and object model. item is also symmetrical with the
equivalent concept in the chandler data model. for that matter, the
chandler term for what i've been calling type is "kind" (event,
contact, task, image, movie would all be kinds).

 > We have prototyped a first approximation of a database schema  (and
 > hibernate mapping files/classes) that pretty closely mirrors the JCR
 > model.  We have done some initial sanity tests to validate performance
 > (shoving 250K events and 1.75M properties into a MySQL db and performing
 > basic queries) and we are in the ballpark.  We are ready to define an
 > object model and service apis that will be surfaced in the cosmo world.


awesome :)

 > So then comes the question of what services we need to expose.  It looks
 > like we need to provide new implementations of UserService and
 > HomeDirectoryService (or maybe just the daos), and then provide a number
 > of services for calendar and dav object access.  These would be the
 > services that you would use when re-writing the jcr-server component.
 > Speaking of which, how do you want to coordinate this?  We can start
 > pretty soon on these services, so what would be the best way to
 > collobarate?  We could give you the api interfaces and then you could
 > start coding the jcr-server based on these(letting us know what changes
 > to the api you need). Suggestions?


i think the first step should be providing alternate implementations
of the dao interfaces. that should provide the least amount of
turbulence in the rest of the system. then, as we re-implement
jcr-server and merge scooby into cosmo and replace its use of caldav,
we'll need to extend the service apis for operations like "get all
calendars in my home collection".

 > Also, if you think of any Chandler requirements outside of a dav/caldav
 > model, let us know so we can make sure there will be some way to support
 > them.


will do. the various sharing format threads are still in brainstorming
mode, but i expect in the next several weeks we'll begin converging on
a concrete plan.

31 jul 12:29

On 7/31/06, Brian Moseley <bcm at osafoundation.org> wrote:

 > i think the first step should be providing alternate implementations
 > of the dao interfaces. that should provide the least amount of
 > turbulence in the rest of the system. then, as we re-implement
 > jcr-server and merge scooby into cosmo and replace its use of caldav,
 > we'll need to extend the service apis for operations like "get all
 > calendars in my home collection".


oh and, mechanically, i'll open a bug in bugzilla for the hibernate
project that you can attach patches to. i'll make an svn branch in
osaf's repository where i'll apply those patches and do the jcr-server
work.