No announcement yet.
  • Filter
  • Time
Clear All
new posts

    Audit remove opearationType issue

    The following audit table has been automatically created using audit="true" in a datasource file. When i remove a row from a listgrid, a new row is added in the audit table indicating that something was removed, but my issue is that it does not fill in all the values of the table. As you can see from the below attachment, pk is filled but ticket_id and user_id for some reason are not filled. This happens only with some audit tables, whereas some other audit tables fill every field as expected.

    What is the reason for that? Is there a way to fix it?

    Click image for larger version

Name:	audit.jpg
Views:	25
Size:	51.8 KB
ID:	270227

    Using SmartClient Version: v11.1p_2021-05-26/Enterprise Deployment (built 2021-05-26)


    In order to address this we need more details. First thing to check is that those audit records with no other than PK field data actually had other data before the removal. If the data was there and the issue is still present, could you please provide detail information on your ds.xml definition you're are auditing? It can be schematic (not a real datasource if the data is sensitive), ideally standalone use case with minimal amount of fields / features involved but still showing the issue.


      When I add new records, I can see them being added to the audit table as expected, with all the field data filled. The issue only occurs with the remove operation, where they are added on the audit table as well, but not all of its field data are filled. Below you can see the audit table with an example of an addition and removal of a record, and also the ds.xml definition of the datasource I am auditing. The only solution I have thought, is to manually update the missing values in the audit table when the remove operation occurs, but I think that is not an optimal way.

      Click image for larger version

Name:	remove.png
Views:	10
Size:	11.8 KB
ID:	270254

      <field name="pk" type="sequence" primaryKey="true" implicitSequence="true"></field>
      <field name="ticket_id" type="integer"></field>
      <field name="user_id" type="integer"></field>


        If you're unable to provide a standalone test case reproducing the issue, we would recommend comparing the DataSources where this audit issue happens with those where it doesn't.

        In particular, we note that you've set implicitSequence="true" on this table. If you read the docs for this property:

        Perhaps all DataSources that have incomplete audit information have this setting?

        Also, you'll note that setting implicitSequence="true" also requires sequenceMode to be set. Perhaps you have not done this, or for whatever reason, the JDBC driver is failing to return sequence values in this case.

        This would all be visible in the server logs, which again is a minimum thing you should share, if you are not able to produce a standalone test case.


          Thank you for your replies. So, I did compare the faulty DataSource with ones that work correctly, but I can't find any differences. And I don't think implicitSequence produces the error, as the other DataSources that work as expected also have this property set.

          Sorry I don't know how to create a standalone test , the only thing I can share with you right now are the DSRequest and Raw Response:

          Click image for larger version

Name:	rpc.png
Views:	7
Size:	45.0 KB
ID:	270258

          As for the server logs, I can't see any issues when removing a record. Maybe I need to change something from the below categories:
          org.hibernate.SQL: INFO
          org.hibernate: INFO
          org.apache.velocity: WARN
          org.apache: INFO
          com.isomorphic.validation.Validation: INFO
          com.isomorphic.timing.Timing: INFO
          com.isomorphic.sql.ValueSet: INFO
          com.isomorphic.servlet.RequestContext: INFO
          com.isomorphic.servlet.ProxyHttpServletResponse: INFO
          com.isomorphic.servlet.PreCache: INFO
          com.isomorphic.resultData.ResultData: INFO
          com.isomorphic.obfuscation.Obfuscator: INFO
          com.isomorphic.naming.JNDI: WARN
          com.isomorphic.js.JSSyntaxScannerFilter: INFO
          com.isomorphic.interfaces.InterfaceProvider: INFO
          com.isomorphic.datasource.DataSource: INFO
          com.isomorphic.datasource.BasicDataSource: INFO
          com.isomorphic.compression.Compression: WARN
          com.isomorphic.base.Reflection: INFO
          com.isomorphic.base.ISCInit: INFO
          com.isomorphic.base.ConfigLoader: INFO
          com.isomorphic.assembly.FileAssembler: INFO
          com.isomorphic: INFO
          Sorry if I don't provide enough information, I just don't know how to find all the information you are asking me.


            We don't need your log settings. We need to log output when you use the default settings.

            This is considered the basics - this is actually something you are reminded of every time you post.

            Is it possible that you've never seen the server logs at all? If so, please look at the Server Logging documentation category and see the related documentation for the Log4j framework. Make sure you have seen the server logs, as this is important not just for this problem, but for just basic use of the framework over time.

            Also, there is no way to not know how to create a standalone test case. A standalone test case is simply code that causes the problem to happen in such a way that anyone can reproduce it. So, if you cannot create a standalone test case, this means that the problem must be in some part of your application, since you cannot show that it is a problem in the framework. This is why we ask for a standalone test case, if you think there is a framework bug.