I'd love to get Derby out - it adds a lot to the footprint. 

I can help with the mapping of data structures to LDAP.  As Emmanuel said the best way is to embellish the page we already have in confluence perhaps with a section on each data structure and we can write out the quartz schema for it.

Looking initially at the DB schema you provided Kiran I can see this will be pretty easy to do.  For starters we will have a quartzTrigger ABSTRACT objectClass with a quartzTriggerName attribute and a quartzTriggerGroup attribute.  This can be extended for quartzCronTrigger, quartzBlobTrigger, quartzSimpleTrigger STRUCTURAL objectClasses.  Under a trigger we can subordinate the jobs the trigger has fired off.  This is oversimplified I know but these are the best steps to take to just knock this out.

It will not be that hard to do.  Once we know the schema and namespace organization it's pretty easy to do and I'm not very worried about the schema design at all.


On Sat, Sep 27, 2008 at 12:05 PM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
Hi Kiran,

first, I suggest that you create a page on the wiki where you put your thoughts about Quartz integration, as it will be more easy to look at the graphics. (when this page is modified, the dev list is notified)

Kiran Ayyagari wrote:

Here are some ideas that I have atm

1. Serialize the in-memory data structures used by quartz and reload them after server startup.
   (may require a separate partition to store)
This is clearly an option. Now, we have to express Quartz needed structure in a hierarchical way.

2. Use an embeddable RDBMS. In this case quartz can directly store data using its inbuilt JdbcStore.
   (This may be the last and least preferable option )
Yep. I would not favor this approach either, but we have to remain open minded ... (all in all, we already embed Derby in ADS to manage replication :)

cordialement, regards,
Emmanuel Lécharny