Re: [castor-dev] Introduction and some questions

Ralf Joachim <[email protected]> Thu, 03 Dec 2009 20:25:07 +0100
Newsgroups gmane.comp.java.castor.devel
Organization Syscon Ingenieurbüro GmbH
Message-ID <[email protected]>
Hi Ivo, Hi Michael,

see my comments inline.

Ivo Friedberg schrieb:

Hello,

At first I want to introduce
myself (Ivo
Friedberg) and a colleague of mine, Michael Schroeder. We are both
studying Informatics
on the Technical University of Vienna and are now participating in a
lecture
called Advanced Software Engineering. In the context of this lecture we
decided
(after a little presentation of Werner) to work on Castor this semester
and so
here we are.

Very much appreciated.

The last month we were up to
learn the basic
understanding of the technology and structure of Castor (some of you
may have
noticed some strange jira issues?!) and now we have actually started
with the underlying
task. This is now to exchange the global AutoStore option with a finer
grained
cascading system. It should work directly in the mapping file allowing
to
specify which operations (create, update, delete,…) should be performed
cascading and which not!

I have recognized these jira issues but had informed by Werner before.

In order to achieve this, we
started
implementing a cascading attribute to the generated java classes in
Castor and
implemented the cascading=”create” option. This should make it able
that only new added objects are stored automatically but no updates or
delete
operations. In order to reach this goal (I think we are nearly there
right now
although it’s some kind of bungling solution right now cause the
attribute is only a String value right now which is going to be checked
;))

Now to our questions:

1.
dependent
objects: we came upon
the question how to treat dependent objects. As far as we found out,
changing
the master object of an depending object ignores the value of autostore
and
always creates the new master object. that seams reasonable, cause by
the means
of dependent objects they have to have a master object. But now we
questioned
whether we should take dependent relations into account while defining
the
cascading attribute, for example always assume cascading create and
cascading
delete as true but not update. This would be possible and there is the
question
whether this is interesting for castor or undermining the idea of the
dependent
objects!

As far as I know about depend every call to Datebase methods load(),
create(), update() or delete() are forbidden for dependent entities and
throw exceptions. For me this seams about similar to what should happen
when one declares a relation cascade=all. The difference between using
depend and cascade=all is, that depend also prevents access to
dependent entities at methods of Database interface. Does that make
some sense?

2.
We where about
to create
some testcases but the question occurred where to put them and how to
set up
the derby database right. Is it better to make an own prpject for
testing our
implementation and not putting the tests directly into the castor
project?

@Werner:
Do you
have any specific wishes how we should treat this?

The testcases should go into cpactf. Its framework will create/drop
tables for you if you supply the scripts and will also initialize
JDOManager. As I have not yet added much javadoc to the framework I
suggest to look at one of the other testcases. Numbering of test
packages relate to jira issue number. If you have questions regarding
the cpactf ask them away by mail or join me on Castor irc where I try
to be online as offen as possible.

Thanks for reading and have a
nice evening,

Ivo

Regards

Ralf

--

Syscon Ingenieurbüro für Meß- und Datentechnik GmbH
Ralf Joachim
Raiffeisenstraße 11
72127 Kusterdingen
Germany

Tel. +49 7071 3690 52
Mobil: +49 173 9630135
Fax +49 7071 3690 98

Internet: www.syscon.eu
E-Mail: [email protected]

Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email