jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rakesh Vidyadharan <rak...@sptci.com>
Subject Re: Jackrabbit & database
Date Sun, 06 Mar 2011 13:19:59 GMT
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 <rakesh@sptci.com> 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: rakesh@sptci.com



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message