Ivo Friedberg
2009-12-03 18:56:44 UTC
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.
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!
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!
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?
Thanks for reading and have a nice evening,
Ivo
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.
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!
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!
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?
Thanks for reading and have a nice evening,
Ivo