I have been learning java spring hibernate MVC for 3 months and got pretty idea of that . But i have not understood what JCR means.
I mean for e.g in my simple webiste in spring MVC what part can be done in JCR
JCR would be an alternative persistence mechanism used in place of JPA (Hibernate), which hides JDBC from your application. In theory, the Java classes you have in your model might remain the same as you have now. However, if any classes in your model came about only because you needed to model some lower-level data structures for JPA, then these classes might not be needed with JCR.
You'd need a good reason to replace an existing use of JPA with JCR. For example, you may have discovered that using JPA requires jumping through a lot of extra hoops and doing things you'd not really need to do.
Having said that, JCR certainly has some advantages and capabilities that are not otherwise found in JPA:
JCR supports structured data, unstructured data, and everything in between. JCR allows a flexible schema and can be very NoSQL-ish. JPA is very structured, with a fixed schema.
JCR is hierarchical - some use cases are extremely hierarchical, and doing that with a relational model can be very difficult/expensive
JCR has built-in events
Most JCR implementations can store content in a variety of systems. Some can even access and federate existing content in other systems.
No length limitation of string values
JCR has full-text search support
JCR has multiple query languages, including JCR-SQL2 (very SQL-like)
There are some libraries that map Java classes to your node structures, and thus are very similar to JPA/Hibernate
It all depends on whether these features are beneficial for your application.
Java Content Repository(JCR), tries to address these problems (and many others) in an implementation-independent way; that is, the API will be the same regardless of the underlying resource (eg a database, a local or virtual file system). Sitting on top of the data storage, JCR offers content services like granular access control, versioning, content events, full-text search and filtering among others. With an impressive expert group behind JSR-170 led by Day Software, including Content Management Systems (CMS) vendors like Vignette, Hummingbird Ltd., Stellent and the usual Java-driven solution providers like BEA Systems, IBM and Oracle, the specification is likely to become the de-facto standard for content management and document storage.
Re. the descision on when to use JCR vs. a relational data model, have a look at david's model. Was an eye-opener for me....
Related
I am using eclipse to develop a java ee web app with Hibernate to provide persistence and an SQL-type interface. Are there any recommended tools for drawing up the relational database model graphically, that can then go on to generate the necessary classes and entities etc for it? Something like the core data tools in Xcode...
There are open source tools, but they are scattershot at best, and the commercial ones can be quite pricey.
I've actually never needed one, except for documentation. Work out the entity relationships in some other fashion (I've used Visio, for instance) and then start setting up your Java code. I've architected systems with dozens of tables with all kinds of relationships, and was never hindered by the fact that I didn't have a GUI tool.
To be honest, some of these tools lock you in, and additionally, you can end up wrestling with their restrictions and quirks as much as with your real work.
One last point: if you need to produce documentation of the DB model, you can use SchemaSpy to generate diagrams of your DB.
My qustion is: How would you go on implementing simple DMS(document management) based on following requirements?
DMS shouls be distributed web application.
Support for document versioning.
Support for document locking.
Document search.
Im already clear on what technologies I want to use. I will use Sring MVC, Hibernate and relational (most likely MYSQL) database.
One thing Im not very clear on is if I need to use webdav, since I could just upload or download documets. I thing I have to because I need to acomplish point 2. and especially point 3. somehow. Is this the right way to go?
Any examples or experience with this would come very handy :). May be Milton is not the best library to pick for webdav?
#Eduard, regarding dependencies on 3rd parties - are you doing this as a college/university exercise or something that will affect real users in a production environment?
At the risk of sounding very pretentious; don't reimplement the wheel! I'd definitely 2nd the call to use JCR, this way you are depending a standard and not a 3rd party implementation.
JCR is a well defined standard (that means a lot of people invested commercial effort (i.e. cash and expertise in huge amounts) into this). I would seriously reconsider looking into JCR - think of it as an API where 3rd parties provide the implementation (no vendor lockin).
Have a look at the features you'll get out-of-the-box, I believe 99 - 110% of the functionality you require is available through a JCR implementation. Plus you'll benefit from the fact the code you'll be using has been tested by hundreds of people in real world situations.
Where I'd differ from bmscomp is in suggesting JackRabbit http://jackrabbit.apache.org/
Option 1:
I am not sure about webdav, no real experience on it. But I would highly recommend you using a Document database like MongoDB.
With mongodb, you can:
1. Handle document versions
2. MongoDB has atomic operations, you can add your logic of document locking.
This will give you some awesome added benefits of search your documents store.
Option 2:
Apache Jackrabbit: A Content repository
A content repository is a hierarchical
content store with support for
structured and unstructured content,
full text search, versioning,
transactions, observation, and more.
Think about using JCR Java content Repository
http://en.wikipedia.org/wiki/Content_repository_API_for_Java or you can have a look at the job done on Alfresco or and Exo framework they did a good job
You can use these open source projects to meet your requirements:
http://sourceforge.net/projects/logicaldoc/ -
LogicalDOC is a modern document management system with a nice interface, easy to use and very fast. It uses open source Java technologies such as GWT, Spring, Lucene in order to provide a flexible and scalable DMS platform. http://www.logicaldoc.com
http://sourceforge.net/projects/openkm/ -
OpenKM Document Management - DMS Updated 2011-05-25
OpenKM is powerful scalable Document Management System (DMS). OpenKM uses Jboss + J2EE + Ajax web (GWT) + Jackrabbit (lucene) Open Source technologies. http://www.openkm.com/
Spring MVC is a good choice. If you want to use a relational database then can also check out Datanucleus. At least the JDO layer (plus maybe the JPA layer) provides versioning support. For search I recommend apache solr, based on lucene, wich has excellent and powerful fulltext search capabilites.
Although webdav seems like the natural choice as a simple and cross plattform file transfer protocol I never had good experiences. Either the Client or the Server didn't work well (konqueror, internet explorer, zope 2, ...). So abstract from the protocol and provide multiple ways to access the file.
may i know in 'nosql' there is limitation just like bigtable where we should 'denormalized' our table/entity ?
any api wrapper that allow we to write code once and can be used for google app engine bigtable and nosql ? (something like hiberanate)
Yes, for example in MongoDB you don't have joins since it is non-relational, so it does change how we store and browse the data.
As MongoDB is non-relational (no
joins), references ("foreign keys")
between documents are generally
resolved client-side by additional
queries to the server. Two conventions
are common for references in MongoDB:
first simple manual references, and
second, the DBRef standard, which many
drivers support explicitly.
It seems that the consensus is to denormalize and duplicate to accelerate the reads to avoid the cost of joining distributed data all toghether, with the join and merge logic done on the application level.
As to whether it is an absolute requirement to denormalize the database, I am not sure (other SO members can probably enlighten us). But I think the database should be modeled with these "limitations" in the mind along with a good study of how the data is going to be queried. This should give the least impedance to the process.
See Also:
Bigtable database design theory
GAE - How to live with no joins?
Any API wrapper that allow we to write
code once and can be used for google
app engine BigTable and nosql ?
(something like Hibernate)
JDO is datastore-agnostic, so it might just provide what you want to some extent.
Seems there are lots of recent projects to use JDO and JPA with "NoSQL" products.
See:
Datanucleus-Cassandra
Datanucleus-Cassandra-Plugin
Any API wrapper that allow we to write code once and can be used for google app engine BigTable and nosql ? (something like Hibernate)
While abstraction libraries definitely help portability, you have to take into consideration the particular platform you're running on. If you're going to go with Google App Engine, you have to be aware of the incurred startup costs inherent with additional abstraction libraries.
You should weigh the pros and cons of using something like JDO or JPA. Also take a look at the Objectify library that offers a more native interface that has the downside of being coupled to the App Engine Datastore.
I've been working on a site idea the general concept is a full text search of documents that also allows user ratings based on these rating I wanted to boost the item's value in the Lucene index. But I'm trying to find if I should extend JackRabbit or just build from the Lucene base. Is there any good way to extend JackRabbit in this way and effect the index or would it be best to work directly off Lucene?
Either way I go I am strongly leaning to using groovy on grails with either the searchable plugin or work directly with JackRabbit is there any major reasons I should just stick to Java?
Clarification:
I would like to boost an item based on the average user rating of an item, is JackRabbit open enough or expandable enough where I can capture user ratings then have those effect the index within JackRabbit or is it so far out of the core of JackRabbit I should just build up from Lucene?
I recommend using JCR, with the implementation of Jackrabbit behind it. JCR allows you to separate between what you store and how you store it.
By staying within a JCR framework, you should be able to easily switch among JCR implementations. (There are several, not just Apache's.) Even within Jackrabbit are many persistence managers, not just Lucene. This flexibility is useful when you want to trade off between storage space and performance.
JCR already includes full text searches and the ability to maintain user ratings. It should be a good fit for your project.
is there any major reasons I should just stick to Java?
Not really. As you probably already know, you can use any Java library with Groovy/Grails, so there's nothing you can do in Java that you can't do in Groovy. Although the contrary is also true, in my experience, it takes a lot more (boilerplate) code to get things done in Java.
Although Java is considerable faster than Groovy, this doesn't necessarily mean your app will be faster if written in Java, as the bottleneck could likely be the database rather than code execution.
As for whether you should use Lucene/Searchable or JackRabbit, it's very difficult to say without knowing much about what you can achieve. All you've told us so far is that you want to index documents and boost certain items in the index. You can certainly do both of those with Lucene.
I would recommend using JCR/Jackrabbit on top of Lucene for a couple of reasons:
1) Your repository structure could readily support document nodes with child nodes that store all of your meta-data including owner, ratings, flagging, comments, etc.
2) JCR is ideal for document/node based app development, providing a lot of the heavy lifting at the framework level while not getting in your way at the app level.
I would recommend you to use Apache Sling, it comes with Jackrabbit/Lucene built-in.
Most of the committers are also involved with Jackrabbit, so it's designed to work well with it -- even better, it's designed to run on top of it.
One of the nice features of Sling is that it mounts the entire JCR repository in the URL space and exposes it via REST endpoints.
So you can access your documents/metadata very easily by doing a simple HTTP request to it. It also allows you to write your own servlets and expose them as REST endpoints. (This is extremely easy -- no fiddling about with applicationContext.xml files, just 1 annotation)
It also allows you to write jsp, esp, groovy, ...
I found an article from 2008 discussing how to call Java code from MySQL. There were a lot of caveats and disclaimers because the process involved working with an experimental branch of MySQL.
For a project I have in mind, it would be very useful to be be able to access Java libraries within MySQL, analogous to Oracle's Java Stored Procedures. Does this capability now exist as a standard feature of MySQL? If not, what open source RDBMSs support something similar to Oracle's Java Stored Procedures?
PostgreSQL supports pluggable procedure languages, and a project exists to extend PostgreSQL with PL/Java as the language.
I don't recommend putting too much code in the RDBMS. Tools to develop, test, and debug code in the application layer are better than tools for code in the RDBMS.
Also many developers don't understand that code inside the RDBMS should obey transaction isolation. They try to send emails from triggers and so forth. I think code with side effects should be in the application layer, so you don't create phantom effects (e.g. an email may notify of a database change, even though the change was rolled back).
If you can use HSQLDB then you can call java methods directly from SQL: http://hsqldb.org/doc/2.0/guide/sqlroutines-chapt.html#N1240C
I fully agree with Bill, but I can imagine business rules being stored (not processed) in the database. I'm thinking of drools here. The engine would be in the application, but the rules could be in the database with a management front-end.
Such a beast would be interesting for scenarios where not only the parameters change, but also the formulas can change.
It is difficult to give good advice based on the limited information that you have provided so far. However:
... the example involves a graph-based data type (chemical structures) that can't be matched to a query using built-in MySQL functions. The Java library would convert the query and contents of a text field into an in-memory object that can by matched. Keeping this logic in the DB layer would, for example, keep joins within the database, which seems like where they belong. That's the idea, at least.
I don't think I would use database-side Java in MySQL for this. Instead, I think I would consider the following options:
Use an object-relational mapping such as JDO or JPA (for example using Hibernate) to deal with the mapping between your graph-based data model and what the database provides. You don't necessarily have to use an RDBMS as the backend, but that is probably the best place to start ... unless you've already found that this is a performance issue.
Take another look at your data model and data access patterns. See if you can figure out some transformation that allows your application's main queries to be implemented as (efficient) table joins without resorting to server-side application logic.
If you do need to use server-side application logic (for performance reasons!) stick with the mechanisms supported by your RDBMS. For example, in Oracle you'd use PL/SQL and PostgreSQL you have a number of options. Be prepared to switch to a different RDBMS that better suits your application requirements.
I (personally) would avoid depending on an experimental branch of some database:
Consider what happens if the experimental branch is not merged back into the main branch. You would be stuck with your code base depending on a branch that is not supported, and is likely to stop being maintained and fizzle out.
Using a (currently) unsupported RDBMS branch will be an impediment to other folks who might want to use your software.
Now obviously, if the long term viability of your software is not a primary concern, you could choose to ignore this advice. But it probably matters to someone; e.g. your research supervisor.
I realise that this is quite an old article, but it bears updating. The ability to call java from a database trigger is is part of the "SQL Routines and Types for the Java Programming Language" (SQL/JRT) standard.
Read more about this on Wikipedia at https://en.wikipedia.org/wiki/SQL/JRT.
Amongst the compliant database engines are..
HyperSQL: http://hsqldb.org/
Oracle: https://www.oracle.com/database/