Inverses - possible new feature for comment

[ConvertFromOldNGs]

by Craig Shearer >> Tue, 21 Dec 1999 1:10:49 GMT

Hello all

I've been thinking... (some may say that's a dangerous thing to do)

One thing that often gets in the way with inverses is that they work all the time. Consider the following real life example from one of our systems:

Class InsuranceProductQuestion
collection property: allMyAnswersToQuestions - type AnswerToQuestionSet

Class AnswerToQuestion
property: myQuestion - type InsuranceProductQuestion

There is an inverse between these two classes in that setting the myQuestion reference on an AnswerToQuestion object causes the allMyAnswersToQuestions collection to be populated.

This all works fine and dandy except that in our application, we often have transient instances of AnswerToQuestion objects. These are used by the application for storing changes made to objects. When the user clicks a finish button in a wizard, these changes are then copied back to the persistent objects. However, this causes problems when the myQuestion reference is set:

Because the AnswerToQuestion object is transient, setting the myQuestion reference to the persistent InsuranceProductQuestion object causes an exception (1215) "Persistent Objects cannot reference Transient Objects". This is a real pain. I have numerous other examples where this has occurred, and we have needed to find less-than-ideal workaround solutions.

For us, the workaround is to add another reference to the AnswerToQuestion class - myPersistentQuestion which has the inverse back to the InsuranceProductQuestion class. For persistents, both the myQuestion and myPersistentQuestion references are set, but for transients, only the myQuestion reference can be set. While this works, it has the following disadvantages:

- it corrupts the purity of the model
- one must be careful that only the myQuestion reference is used, and not the myPersistentQuestion reference as this may be null.
- the second reference is difficult to name, as it exists only for implementation reasons

I would like to suggest a new feature - how about, when defining an inverse, having a facility for saying when the inverse will be maintained:

1. Always maintain inverse
2. Only between objects with compatible lifetimes

The second option would mean that inverses would only be maintained between persistents or transients, but not between mixed object lifetimes.

What do you think of this idea?

Craig.

[ConvertFromOldNGs]

by Graeme Joyce >> Tue, 21 Dec 1999 2:25:30 GMT

Craig

I have exactly the problem you mention and have overcome it by doing things like:

if self.isTransient then
<some workaround>
else
<set a reference to a persistent object>
endif;

The transient instance is used for holding details of updates for later committal to persistent objects - exactly as in your case.

What you propose certainly sounds useful to me.

Graeme Joyce

[ConvertFromOldNGs]

by Dean Cooper >> Tue, 21 Dec 1999 3:01:10 GMT

Craig,

This is a good idea. In fact, it's such a good idea that yesterday I started working on it! Must be collective consciousness at work This facility has been mentioned to us before a couple of times and is also a requirement for the JADE Report Writer. The initial implementation will provide a method (probably on either Process or Application) that will allow you to specify dynamically for a process whether inverses are to be maintained always, or only for objects of compatible lifetimes. Note that this will be at a process level, so it will set the policy for *all* inverses in the system from the point of view of that process. Your idea of being able to specify the policy on the inverse itself when you define it is good, and I think we should look at implementing that in a subsequent release. Note that this change will allow only a transient to reference a persistent via a reference that has an inverse; a persistent still will not be allowed to reference a transient.

Dean.

[ConvertFromOldNGs]

by Paul Mathews >> Mon, 20 Dec 1999 19:04:25 GMT

Why not subclass AnswerToQuestion with
AnswerToQuestionT which only has transient Instances and an extra Reference myQuestionT.

myQuestion is never assigned in AnswerToQuestion but myQuestionT is.

There is no ambiguity of having mixed transiency of instances.
Obvioulsy a Method to save an AnswerToQuestionT permantently can be made..




Paul Mathews
pem@cmsystemsgroup.com.au
Phone: [612] (99717384) Fax[612] (99711679)
(Dee Why,Sydney,Australia)

Please visit our homepage cmsystemsgroup.com.au.

[ConvertFromOldNGs]

by Craig Shearer >> Tue, 21 Dec 1999 9:48:39 GMT

Hi Paul

You suggest a possible solution to the problem, and in fact, this was the one that I originally tried. There are some complications though.... so, here's my little tale of woe!

Firstly, in our system, the AnswerToQuestion class is abstract and has subclasses . Therefore, if I were to do this via subclassing, I would have to have a Transient subclass for every AnswerToQuestion subclass. As it happens, there are only two subclasses (BooleanAnswerToQuestion, ObjectAnswerToQuestion), but there could easily be more.

Secondly, and this was the complicating factor, when the application runs, the AnswerToQuestion objects (of which there can be many) are stored in a transient collection, keyed on the myQuestion reference. The application needs to be able to look up AnswerToQuestion objects using the InsuranceProductQuestion object as a key. Therefore, for the system to work properly, the myQuestion reference needs to refer to the InsuranceProductQuestion object, but we can't do this for the reasons previously outlined.

So, in the subclassing solution, my solution to having to have this reference populated was to have a mapping method that, when read, would return the transient subclass's non-inverse reference to its InsuranceProductQuestion object.

Here's the code:

myQuestion(set: Boolean; value: InsuranceProductQuestion io) mapping; begin

if not set then
value := myTransientQuestion;
endif;
end;

So, when the myQuestion property is read, it appears to contain the correct reference, even though, in reality, it is null. Now, this all works fine in JADE 4.2, on which the system is currently deployed, but we've just tried upgrading it to JADE 5.

In JADE 5, there is now a pesky new 1250 exception (you bastard, Dean Cooper!!!) that fires if you use a mapping method to return a value different from the value held in the corresponding property (which in this case, is null). This has been done to close a loophole that COULD cause logical database corruption concerning automatically maintained inverses. In this case, it would have been harmless, as the objects are always transient.

So, having explained all that, hopefully you can see why I chose to go down the path I did. I should have explained all this in the original post, but thought it too complex to explain. Now, perhaps you can appreciate my reasoning.

Craig.

PS - have a Merry Christmas and a Happy New Year - and try not to think about work too much!!!

[ConvertFromOldNGs]

by Dean Cooper >> Tue, 21 Dec 1999 21:43:25 GMT

In JADE 5, there is now a pesky new 1250 exception (you bastard, Dean Cooper!!!) that fires if you use a mapping method to return a value different from the value held in the corresponding property (which in this case, is null). This has been done to close a loophole that COULD cause logical database corruption concerning automatically maintained inverses. In this case, it would have been harmless, as the objects are always transient.

In this particular case, the mapping method would have been ok not because the object is transient, but because myQuestion is null and therefore not currently participating in a relationship. Once an object is present in the "many" end of a relationship, such a mapping method *will* break automatic maintenance of the relationship if it returns a different key value; regardless of whether the member object is persistent or transient. I can think of (at least) four systems we saw with this problem in Jade 4 caused by mapping methods doing similar things to what you describe (which effectively turns non-key properties into implicit keys that JADE knows nothing about, because of their involvement in the mapping method). In some of the mapping methods I've seen, this behaviour was unnecessary and/or wrong, and the mapping methods were changed. Others, like yourself, were using a mapping method to encapsulate a transient reference. This is another reason why we want JADE to allow a transient to reference a persistent without maintaining an inverse reference from the persistent. With this facility, you won't need a secondary reference, therefore eliminating the need for a mapping method.

Dean (aka You Bastard)

[ConvertFromOldNGs]

by Silver Springs ... >> Tue, 21 Dec 1999 22:41:38 GMT

Dean (aka You Bastard)

Craig -- a little strong here ... at times you need to be reined in ... especially in this season of goodwill to all men ... (although I know you meant it in "a loving caring way ..." ) ........................................

[ConvertFromOldNGs]

by Craig Shearer >> Tue, 21 Dec 1999 23:41:48 GMT

Of course I meant it that way.... didn't you detect the friendly intonation in my writing?

[ConvertFromOldNGs]

by White >> Fri, 29 Sep 2006 14:05:47 GMT

Hi, nice site here! Check mine: http://erotic.scuko.info/erotic.html <a href=http://erotic.scuko.info/erotic.html>erotic</a> erotic

[ConvertFromOldNGs]

by Craig Shearer >> Tue, 21 Dec 1999 23:27:57 GMT

Dean - are you saying that the exception shouldn't have fired? - 'cos it did!