Chiming in;

As it happens I'm currently working on a NoSQL (Cassandra) project and found a 
JPA implementation for Cassandra ( Currently 
JPA is the most used persistency API in Java, allowing for binding with RDBMS, 
XML, NoSQL. I decided not to use it, BTW, but that is because of other 

To also have an quick opinion on the rest of the thread (as I understand it). Java 
projects have a tendency to over complicate and bloat. For example, wicket convention 
dictates that all labels should be put in property files. I decided not to do that. I 
fully understand the advantages, but for this project I'm simply not going to add an 
additional label component and a property file just to get "Name" on the 
screen. Yes, if it must be internationalized I have to rework my code, but as it stands 
the application probably won't have to be, and I would have added the abstraction for 

Same goes for the 6 line JPA example a few posts back. If it works, great, just 
use it as is. Why make it more complex from the start? Refactor if you need to, 
not overarchitecture in advance.

I found that this pragmatic style (mind you; it's all a balance, you can't skip every corner), usually 
delivers results "PHP style" fast, but still has "Java quality" architecture in the 
overall setup. And even with all refactoring counted in, it stays well within budget; I'm currently aiming to 
complete my project in 75% of the "Java architecture" estimate. ;-)

Coming full circle; one of the corners you can't cut is clear separation of 
concern. So extracting the model (JPA) from the presentation (wicket) is very 

My 2 euro cents. And thanks for a well though through framework, I'm warming up 
to it.


On 2012-05-13 09:51, wrote:
Has your company heard of NOSQL?

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to