If you really want a database structure that you can control, you should probably go with ModeShape rather than JackRabbit. ModeShape will let you access an existing database using a JCR API, and also help to aggregate various data sources into a single JCR view.
Most JackRabbit queries are run against Lucene indices, and for a majority of cases the query performance is better than a SQL query against a RDBMS. However, complex join queries will be an issue, and will usually require you to aggregate/composite the results through discrete queries against the store. Having said that, in my experience most complex query requirements are a direct consequence of the relational data model and usually not a business requirement. When you model data for a nosql store (JackRabbit should be thought of in that light), you need to disregard old relational modelling techniques, and think purely in terms of domain/object/document modelling. If you do that, you will usually end up with very simple queries instead of complex join queries. Rakesh On 6 Mar 2011, at 02:23, Reza Aliakbari wrote: > Thanks Rakesh for the detailed answers. > > Actually I am not sure whether JCR and Jackrabbit with the Bundle model will > satisfy all functional needs(complex queries for example) that we would face > during development of our product. Also if it is possible, how would be the > performance. > > So I thought the things should not be like a black box that whole things are > in the hand of Jackrabbit. In real applications we would need complex > queries and I have doubt Jackrabbit with Bundle model can response well to > such usecases. So I thought to use Jackrabbit for write and simple reads and > for complex queries we would directly use database. > > > Thanks, > > Reza > > > > > > On Sun, Mar 6, 2011 at 1:47 AM, Rakesh Vidyadharan <[email protected]> wrote: > >> >> On 5 Mar 2011, at 15:26, Reza Aliakbari wrote: >> >>> Hi, >>> >>> I downloaded the Jackrabbit WAR file and configured it with a database(I >>> defined PersistenceManager at repository.xml). I hoped to see my nodes >> and >>> main information there at my database but I saw there 4 tables BINVAL, >>> BUNDLE, NAMES and REFS that couldn't find any meaning full information >>> there. >> >> This is certainly the case if you use the Bundle persistence managers. >> These persist the entire node (along with its properties) as one blob into >> the data store (note I refer to it as data store and not database). You can >> try using the non bundle PM's, which may give you more granular tables (I >> have not used them so am not sure). >> >>> >>> I want to know whether it is possible to query the database of Jackrabbit >>> without using its API and see what's going on? for example is it possible >> to >>> see the list of actions that has applied on a node? Where are such infos >>> persisted? >> >> That would be against the principles on which the JCR API was developed. >> The goal was to develop a vendor and persistence neutral API that can be >> used to access you content. The data store can be a relational database, a >> file system, some other network storage, or a combination of these. If your >> need is to access a regular RDBMS, I would question your decision to use >> JCR/JackRabbit in the first place. >> >>> >>> My goal is to be able to fetch all activities and data without needing to >>> access Jackrabbit API. >> >> >> Note that you should try as far as possible to not use the JackRabbit API, >> and use only the JCR API. >> >> Rakesh Rakesh Vidyadharan President & CEO Sans Pareil Technologies, Inc. http://www.sptci.com/ | 100 W. Chestnut, Suite 1305 | Chicago, IL 60610-3296 USA | | Ph: +1 (312) 212-3933 | Mobile: +1 (312) 315-1596 | Fax: +1 (312) 276-4410 | E-mail: [email protected]
