Order of Processing Woes

This isn't really answering your question, but ...

I would avoid the problem by not setting things up this way.  My recommendation is to *not* duplicate method names between A and B with one exception and that is where a method is defined as abstract in A and the implementation is in B, i.e., it is functioning in the same fashion as an interface.  Having a clear and distinct signature for each is going to eliminate the kind of issues you are facing and I think is just good OO design because it recognizes the distinctiveness of A and B.  I.e., if there is some common stuff to do when one fails, put that in A and then define a method in B that is BFail or whatever (hopefully conveying why this is different) and have it do what it needs to do and call the A:Fail when and if appropriate.  If it makes no sense for A:Fail to be called directly by anyone outside, then make it protected, call it something like CommonFail, and you can name the method in B just plain Fail.

BTW, I hope there is a C which also inherits from A since it is an OO no-no to have only one child for a parent.

tamhas wrote:
This isn't really answering your question, but ...
I would avoid the problem by not setting things up this way.  My recommendation is to *not* duplicate method names between A and B with one exception and that is where a method is defined as abstract in A and the implementation is in B, i.e., it is functioning in the same fashion as an interface.  Having a clear and distinct signature for each is going to eliminate the kind of issues you are facing and I think is just good OO design because it recognizes the distinctiveness of A and B.  I.e., if there is some common stuff to do when one fails, put that in A and then define a method in B that is BFail or whatever (hopefully conveying why this is different) and have it do what it needs to do and call the A:Fail when and if appropriate.  If it makes no sense for A:Fail to be called directly by anyone outside, then make it protected, call it something like CommonFail, and you can name the method in B just plain Fail. 

I actually thought of doing that, just didn't get to that point yet. Although, I'm not complete convinced that I agree with it being "good OO".  For example, let's say you have ClassParent, it defines method Fail. In that, you do normal fail work.  Then you have sub-clasess A-whatever. You may want A to get the generic failure, B to do something special, C to do something a little different from B, etc. So conceptually, I think it makes more sense for them to be the same name IF there could be cases/sub-classes where you'd want to just use the super.

(That said, in my current use case, the super:Fail is actually protected and always overridden, so I'm ok with renaming it... Not sure that's the issue though.)

BTW, I hope there is a C which also inherits from A since it is an OO no-no to have only one child for a parent.

Yep :-) There is another child. The original design was just the main class with some case statements in a few of the methods, and a property that wasn't really needed for one of the cases. I decided they were different enough that they should really be two child classes. Much easier to understand from a conceptual point.

They really should be different names because they are different behavior responsibilities.  It is perfectly reasonable to have A with StandardFail and B, C, and D children with just Fail(), the method using classes call, and for B's Fail method to consist of nothing more than a call to StandardFail.  Even though B:Fail() does nothing that StandardFail() doesn't do, they have different roles.  One is the method which using classes call in case of failure and the other is the common failure action for this inheritance tree.

BTW, you might also want to consider delegation as an alternative to inheritance.

your pseudo code has me somewhat confused. Easy, I know, but still ..

are you creating a new dbrecord

1) for every change of status,

2) for every logmessage,

3) or simply for each instance of the class ?

#0  Each method has it's own buffer. There are no scoping problems, no bleeding locks.

#1 Each db update must be wrapped in a transaction

so your code should look like:

Class AParent:

def var SomeID as char no-undo.

Method Init:

def buffer MyLog for MyLog.

do transaction:

     create dbrecord MyLog.

     set various MyLog.values.

assign SomeID = MyLog.UniqueID.

end

  End Method.

Method updateStatus(pStatus as char):

def buffer MyLog for MyLog.

do transaction:

     if available(MyLog) then MyLog.Status = pStatus.

end.

  End Method.

etc etc. The difference in speed is neglibile. Try it.

Regarding the red line,

#1 look at the index that you are using to display the records

#2 make absolutelty sure that you are not mixing records from different logs ..

are you creating a new dbrecord

1) for every change of status,
2) for every logmessage,
3) or simply for each instance of the class ?
#0  Each method has it's own buffer. There are no scoping problems, no bleeding locks.
#1 Each db update must be wrapped in a transaction

Well... 2 & 3 actually. There's actually a parent/child database thing. I have one "Log" record in on table. And them multiple "LogEntry" records in another table. So my init, creates the "Log" table record and nothing else (one for each instance). Then my logMessage method creates a single "LogEntry" record with the message. And there's actually status record in both the Log and LogEntry records as the caller may do a "Success" call so I want to log that even though the whole thing may fail in the end when I'm wrapping things up. (Long story there, but moving files at o/s level, etc. after the user is "done".)

So I would have thought no scoping/bleeding issues either but alas, something was off... However, what if my program crashed or did an abend and my destructor doesn't do anything. Is it *possible* that Progress left something lying around? That's what seemed to have happened. This happened on a test case where I didn't have some things set up correctly so my program which should have worked, failed for a reason my code hadn't considered and it never completed everything on the run before this odd one.

Class AParent:
def var SomeID as char no-undo.
Method Init:
def buffer MyLog for MyLog.

do transaction:
     create dbrecord MyLog.
     set various MyLog.values.
assign SomeID = MyLog.UniqueID.
end
  End Method.
Method updateStatus(pStatus as char):
def buffer MyLog for MyLog.

do transaction:
     find MyLog where MyLog.UniqueID eq SomeID exclusive no-wait no-error.
     if available(MyLog) then MyLog.Status = pStatus.
end.
  End Method.

I do have SomeID defined so good there. However, I do not have my code doing a new find in each method/property. That was a question I had. Is that really:

A - Needed?

B - Best Practice?

That would seem to cause a lot of extra work.  My actual class has several methods and several properties that act on that database record. So are you suggesting that each method/property needs to re-find that record? Then each of my properties that encapsulate a field of that record would need to re-read the record? Each method that uses the record needs to read the record?

I started down that path, but that seemed overkill and also didn't match up with some of the examples I had seen. It seems to me it would make since to scope the record to the class. But, I'd certainly be interested in everyone's thought and experience on that because I was heading in that direction and it sounds like you suggest that as well. (Although, now that you have me thinking more about transaction scope that alone may make it necessary to do all of those extra reads, at least for the places I need to do a write.)

#1 look at the index that you are using to display the records
#2 make absolutelty sure that you are not mixing records from different logs ..

The index is good, it's a datetime field at the end so messages unique to the ms, and I'm not mixing logs unless something didn't get cleaned up and was hanging around from a prior run. See above note, but the run before the one that had out of order statements had failed in a case that I was not catching so I'm of the opinion that something was still around in the world...

Thank you much for the thoughts.

Thank you for your message. I am currently out of the office, with limited access to email.

I will be returning on Monday, 06/18/12.

Brent

jmls wrote:
Class AParent:
 def var SomeID as char no-undo.
Method Init:
 def buffer MyLog for MyLog.
 do transaction:
     create dbrecord MyLog.
     set various MyLog.values.
assign SomeID = MyLog.UniqueID.
end 
  End Method.
etc etc. The difference in speed is neglibile. Try it.

Thanks Julian. I had to step away and think and you pretty much have to do the db work inside of each method/property otherwise things could get funny. I was making a (false) assumption that the object would be around and working properly as long as I needed to access things and that's just not neccesarily true. For instance, I had an o/s error and that made things behave different that my code expected so, quite possible that something was strange. I guess if I re-do finds in every case, I'm always at least sure of the scope and type of lock.

That said... what about READS of that record?  Would you just have every single method/property that needs to access the record read it (no-lock or exclusive, whichever it needs?)

Thanks again. It's a lot of find statements but I guess in the end, the thing should be in memory and I'm accessing with a unique key so it really shouldn't take a lot of time. (I hope).

afutrel wrote:
Thanks Julian. I had to step away and think and you pretty much have to do the db work inside of each method/property otherwise things could get funny. I was making a (false) assumption that the object would be around and working properly as long as I needed to access things and that's just not neccesarily true. For instance, I had an o/s error and that made things behave different that my code expected so, quite possible that something was strange. I guess if I re-do finds in every case, I'm always at least sure of the scope and type of lock.
That said... what about READS of that record?  Would you just have every single method/property that needs to access the record read it (no-lock or exclusive, whichever it needs?) 
Thanks again. It's a lot of find statements but I guess in the end, the thing should be in memory and I'm accessing with a unique key so it really shouldn't take a lot of time. (I hope).

Again, I generally always scope the table to the method, so a find would have to be re-read. IMHO it's always best to try and make the scope of the buffer as small as possible. Less surprises that way