FWD » Core Development » Database

Add support (conversion and runtime) for the following:

BUFFER:NUM_FIELDS
QUERY:SKIP-DELETED-RECORD
TEMP-TABLE:UNDO

I continued investigations on SKIP-DELETED-RECORD but without success. I checked the GUI sources and there are only two occurrences. I will try to isolate a testcase starting from those files.
I understand that this should be similar to SET DELETED statement from dbase/foxpro that works with DELETE/RECALL. This attribute would be meaningful if a RECALL statement would be available in Progress, but AFAIK, there is none. The only way to 'recall' deleted records is to rollback a transaction. I will attempt tomorrow to duplicate/isolate a such construct on windev01 a query with a transaction, too.

The UNDO attribute seems to be wrongly placed. In fact, I believe that we should better distinct between methods and statements of a Progress TEMP-TABLE handle. They are put together in OE docs. However, there are two kind of attributes and methods: for design of the dynamic temp-table, that should unwrap to the builder class, and runtime of a temp-table. If for the first kind unwrapping to TempTable looks fine, the second kind should be unwrapped to Temporary or, probably better, to TemporaryBuffer.
For example, converting:

h-tt56 = buffer tt56:handle.
MESSAGE h-tt56:has-records.

Tt561_1.Buf tt56 = TemporaryBuffer.define(Tt561_1.Buf.class, "tt56", "tt56", false);
[...]
hTt56.assign(tt56);
message(new Object[] { hTt56.unwrapTempTable().hasRecords() });

Further investigations I realized in the second half of my previous note I was wrong. Please ignore that part.

The implementation of UNDO attribute is done for dynamic temp-tables.
However, I discovered that the same attribute of static temp-tables are also alterable. I committed some testcases that demonstrate this (uast/undo/changing-undo-for-temp-tables.p, uast/undo/undo-attribute-dynamic-temp-table.p, uast/undo/undo-attribute-static-temp-table.p).
There is a little more work here, because the NO-UNDO flag is converted statically into the buffer definition. Most likely, nobody will alter the attribute, but I would like to do the full implementation of this attribute.

I am a little concerned about some exceptions that are printed to console, when the external procedure is finished. It looks like we already encountered something similar:

[10/23/2015 22:54:04 EEST] (com.goldencode.p2j.persist.Persistence$Context:WARNING) [00000002:0000000C:bogus-->local/_temp/primary] rolling back orphaned transaction
[10/23/2015 22:54:04 EEST] (com.goldencode.p2j.persist.RecordBuffer:WARNING) Error rolling back transaction
com.goldencode.p2j.persist.PersistenceException: [00000002:0000000C:bogus-->local/_temp/primary] error persisting object
        at com.goldencode.p2j.persist.Persistence.handleException(Persistence.java:4075)
        at com.goldencode.p2j.persist.Persistence.save(Persistence.java:2768)
        at com.goldencode.p2j.persist.RecordBuffer.flush(RecordBuffer.java:5468)
        at com.goldencode.p2j.persist.RecordBuffer.setCurrentRecord(RecordBuffer.java:9421)
        at com.goldencode.p2j.persist.RecordBuffer.finishedImpl(RecordBuffer.java:8746)
        at com.goldencode.p2j.persist.RecordBuffer.finished(RecordBuffer.java:5176)
        at com.goldencode.p2j.util.TransactionManager.processFinalizables(TransactionManager.java:4990)
        at com.goldencode.p2j.util.TransactionManager.popScope(TransactionManager.java:2295)
        at com.goldencode.p2j.main.StandardServer.invoke(StandardServer.java:1394)
        at com.goldencode.p2j.main.StandardServer.standardEntry(StandardServer.java:427)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at com.goldencode.p2j.util.MethodInvoker.invoke(MethodInvoker.java:76)
        at com.goldencode.p2j.net.Dispatcher.processInbound(Dispatcher.java:705)
        at com.goldencode.p2j.net.Conversation.block(Conversation.java:319)
        at com.goldencode.p2j.net.Conversation.run(Conversation.java:163)
        at java.lang.Thread.run(Thread.java:745)
Caused by: org.hibernate.NonUniqueObjectException: a different object with the same identifier value was already associated with the session: [com.goldencode.p2j.persist.dynamic._temp.impl.DynamicRecord1Impl#1]
        at org.hibernate.event.internal.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:180)
        at org.hibernate.event.internal.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:136)
        at org.hibernate.event.internal.DefaultSaveOrUpdateEventListener.saveWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener.java:204)
        at org.hibernate.event.internal.DefaultSaveEventListener.saveWithGeneratedOrRequestedId(DefaultSaveEventListener.java:55)
        at org.hibernate.event.internal.DefaultSaveOrUpdateEventListener.entityIsTransient(DefaultSaveOrUpdateEventListener.java:189)
        at org.hibernate.event.internal.DefaultSaveEventListener.performSaveOrUpdate(DefaultSaveEventListener.java:49)
        at org.hibernate.event.internal.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:90)
        at org.hibernate.internal.SessionImpl.fireSave(SessionImpl.java:756)
        at org.hibernate.internal.SessionImpl.save(SessionImpl.java:748)
        at org.hibernate.internal.SessionImpl.save(SessionImpl.java:744)
        at com.goldencode.p2j.persist.Persistence.save(Persistence.java:2753)
        at com.goldencode.p2j.persist.RecordBuffer.flush(RecordBuffer.java:5468)
        at com.goldencode.p2j.persist.RecordBuffer.setCurrentRecord(RecordBuffer.java:9421)
        at com.goldencode.p2j.persist.RecordBuffer.finishedImpl(RecordBuffer.java:8746)
        at com.goldencode.p2j.persist.RecordBuffer.finished(RecordBuffer.java:5176)
        at com.goldencode.p2j.util.TransactionManager.processFinalizables(TransactionManager.java:4990)
        at com.goldencode.p2j.util.TransactionManager.popScope(TransactionManager.java:2295)
        at com.goldencode.p2j.main.StandardServer.invoke(StandardServer.java:1394)
        at com.goldencode.p2j.main.StandardServer.standardEntry(StandardServer.java:427)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at com.goldencode.p2j.util.MethodInvoker.invoke(MethodInvoker.java:76)
        at com.goldencode.p2j.net.Dispatcher.processInbound(Dispatcher.java:705)
        at com.goldencode.p2j.net.Conversation.block(Conversation.java:319)
        at com.goldencode.p2j.net.Conversation.run(Conversation.java:163)
        at java.lang.Thread.run(Thread.java:745)

Task branch 2618a created from main trunk revno 10950. It contains the implementation of UNDO attribute and fixes for exception above. Committed revision 10951.

Code review 2618a/10951:

• either add a header entry to BufferManager or back out the whitespace-only change;
• typo in the comment at DynamicTablesHelper:1472;
• typo at RecordBuffer:907.

You can test this branch any time you're ready, but we will not merge to trunk until after 2677a, so please plan accordingly.

Nice work tracking down and fixing the NonUniqueObjectException.

Guy,

From the initial list, the SKIP-DELETED-RECORD is the only attribute that lacks support in p2j. I was not able to understand how the mechanism work. As I wrote in a previous note, the documentation is very limited and I was not able to create a testcase on windev01 that demonstrates the influence of this attribute. In GUI sources, there are only two usages (adcdedi1.w and adcdedi2.w). In both occurrences, the value is set to true, which I realized it's the default value (from my investigations), so the statements are in fact no-ops.
Could you provide a simple example of usage of this attribute where its effect is visible, please?

Hi Ovidiu,

To be honest I didn't know about the existence of that attribute, nor what it did.

Looking at the code, a temp-table is built up (the available records), and then the selected records are removed from the available records temp-table and added into a selected records temp-table. Perhaps whoever originally wrote that code was worried that by removing records out of the original query, it would result in it not functioning correctly. I guess the code was tried with the attribute set, and it worked, so it was left in.

I think that rather than both of us wasting time investigating SKIP-DELETED-RECORD, we just amend the code to remove these statements. If you ever get another customer who actually uses SKIP-DELETED-RECORD (= FALSE), then you can investigate it then.

Hope that's OK.

Regards,
Guy

I've updated the bzr repo on lincon01 with versions of adcdedi1.w and adcdedi2.w with the references to SKIP-DELETED-RECORD removed.

Thanks, Guy.

Code review 2618a/10952:

Ovidiu, all looks good. To double-up on regression testing, I'm going to be making updates to 2618a for my work in #2692. Once that's ready, I'll get back with you about regression testing this branch.

Code review 2618a/10953:

Changes look good. Due to the regression found in 10952, I separated my work for #2692 into a separate branch (2692b). So, 2618a now will contain only your changes. Please regression test. I'll try another run of unit tests with 2618a tonight and let you know the results.

On second thought: Greg, would you prefer we hold off regression testing 2618a and 2692b until you've merged 2677a to trunk, then rebase those branches and test that? I don't think there should be much/any overlap with 2677a (which is why I suggested we test 2618a), but I understand it would be more painful to rebase 2677a than the other two branches.

There is no need to wait on testing. Get it done now and then merge into 2677a. Do not merge to trunk.

Common search and full search unit tests went OK with 2618a/10953. Running sysmaint and developer tests next...

Sysmaint tests were OK.

Developer tests were OK.

If normal regression testing goes well, please merge the changes to 2677a.

Can we close this?

The update was merged into task branch 2677a as revision 11046. 2677a is already in trunk.
I believe we can close this issue.