Thanks Alex! I was able to use the persistence manager with a local SQL Server DB, and I could see that some tables were created in the database (residing in a SQL Server Database Primary Data File on the server data directory). The tables that were created were the Property and node tables, with PROP_ID, PROP_DATA as columns for the Property tables, and NODE_ID, NODE_DATA as columns for the Node table.
I am accessing the nodes directly now to retrieve data and add any additional properties to my objects. Thanks a lot for illuminating my thought process on this. Regards Anit -----Original Message----- From: Alexander Klimetschek [mailto:[email protected]] Sent: Tuesday, September 29, 2009 10:16 AM To: [email protected] Subject: Re: recursive XPath in jackrabbit... On Tue, Sep 29, 2009 at 18:38, Phukan, Anit <[email protected]> wrote: > So is it advisable to use the DBFileBased system wherein we write our > objects to specific nodes on a DB file system, and add properties later > on as opposed to actually creating tables for nodes and properties? No, the FileSystem is actually a legacy component in the internal jackrabbit persistence architecture. The important part is the persistence manager, see [1]. The bundle DB persistence managers are recommended for performance and stability. They will create their own tables upon first access in the database, which are not really intended to be accessed by other applications, as they are internal and contain most information in binary blobs (node bundles, hence the name). The idea behind that is to give you a JCR API, which is completely independent from whatever storage (eg. relational db is below) and clients don't have to care about. Unstructured data is supported without further ado. How you map your objects onto JCR itself is another topic... you can use jackrabbit-ocm, jcrom or even drop object mappings and always access nodes directly (my opinion), as the JCR Node interface is already kind of a DAO. [1] http://wiki.apache.org/jackrabbit/PersistenceManagerFAQ Regards, Alex -- Alexander Klimetschek [email protected]
