Leszek Gawron wrote:
Antonio Gallardo wrote:
I will suggest OJB instead - http://db.apache.org/ojb/.
On the contrary I strongly recommend Hibernate :)
I was working on a hibernate the last weeks and I need to say that I
prefer OJB. Here 2 samples:
1-When using a java List for a collection inside a bean, in Hibernate
the table need an additional field to manage the order of the table
rows! What is that?
That is the persistent order of your collection. A list needs to know
what is the sequence of it's child beans. How do you do it in OJB?
Using "orderby" attribute -
http://db.apache.org/ojb/docu/guides/repository.html#collection-descriptor
There is no need of an extra field.
2-I don't want in my database more fields than what I need, so let
replace the Java List witth a Java Set --> then I meet a new problem:
cforms binding use jxpath and jxpath don't work with Sets. jxpath
throws an Unsupported Operation Exception! Boom!
strange:
<fb:context xmlns:fb="http://apache.org/cocoon/forms/1.0#binding";
xmlns:fd="http://apache.org/cocoon/forms/1.0#definition";
xmlns:ci="http://apache.org/cocoon/include/1.0";
path="/" >
<fb:repeater id="questionDefinitions" parent-path="."
row-path="questionDefinitions" direction="load">
<fb:identity>
<fb:value id="id" path="id"/>
</fb:identity>
<fb:on-bind>
<fb:value id="questionName" path="name"/>
<fb:value id="questionCategory" path="category/name"/>
</fb:on-bind>
</fb:repeater>
</fb:context>
In this case I have bound SurveyDefinition.questionDefinitions
collection and it works.
In my case, I met the Unsupported Operation Exception in jxpath using
@direction="save" not while loading a not with a repeater, but using a
cform multivalue field.
I wonder how people using hibernate deal with this situations. The
1st shows me a poor database desing and the second a restriction to
use cforms at all!
I still do not get why this is a poor database design. In hibernate
you can use:
1. unordered set
2. a treeset ordered with Comparable contract
3. a List which has a persistent order of your choice.
Only the third choice for obvious reasons needs an indexing column.
What is the obvious reason? IMO, an additional index field shows a poor
database design.
Best Regards,
Antonio Gallardo.
