castor
  1. castor
  2. CASTOR-3074

An extended entity are loaded twice when the entity are loaded as the super class type

    Details

    • Type: Improvement Improvement
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.3.2
    • Fix Version/s: 1.3.3rc1
    • Component/s: JDO
    • Labels:
      None
    • Number of attachments :
      3

      Description

      Suppose class A and B, and B extends A, and an object with key 1 is an instance of Class B.

      Now we load (A, 1), the SQLStatementLoad.executeStatement method will be executed twice, and the select statement will be executed twice, too. Because A is the superclass, then in the first execution, the concrete class is determined, and in the second execution, the entity are loaded and molded.

      If we load (B, 1), the SQLStatementLoad.executeStatement will execute once.

      I think the second execution will not be so necessary, it may be a performance problem. We should eliminate the second execution.

      1. patch-C3074-20110710.txt
        9 kB
        Wensheng Dou
      2. patch-C3074-20110717.txt
        8 kB
        Wensheng Dou
      3. patch-C3074-20110718.txt
        5 kB
        Wensheng Dou

        Activity

        Hide
        Wensheng Dou added a comment -

        In this patch, I'll cache the first result in the SQLStatementLoading.executeStatement, then I'll use the cached results in the second loading.

        If I'll just cache the results, the test96 will fail, because in test96, the first loading will not load the whole object, so I make changes with "addCols(tbl, joinTableInfos, mainTbl, true);". Then the first loading will get all the columns about the ExtendedObject.

        Show
        Wensheng Dou added a comment - In this patch, I'll cache the first result in the SQLStatementLoading.executeStatement, then I'll use the cached results in the second loading. If I'll just cache the results, the test96 will fail, because in test96, the first loading will not load the whole object, so I make changes with "addCols(tbl, joinTableInfos, mainTbl, true);". Then the first loading will get all the columns about the ExtendedObject.
        Hide
        Ralf Joachim added a comment -

        Even if the solution shown would solve the problem I do not like to cache resultset in ProposedEntity.

        As SQL queries for all entities of an extends hierarchy are almost the same already and we already know the correct class, wouldn't it be better to always return the Object array needed for this class with the first call to load. If we do so we could remember Object array in Lockengine or ClassMolder and could eliminate the second call to load.

        Let's discuss about that when we meet on IRC next time.

        Show
        Ralf Joachim added a comment - Even if the solution shown would solve the problem I do not like to cache resultset in ProposedEntity. As SQL queries for all entities of an extends hierarchy are almost the same already and we already know the correct class, wouldn't it be better to always return the Object array needed for this class with the first call to load. If we do so we could remember Object array in Lockengine or ClassMolder and could eliminate the second call to load. Let's discuss about that when we meet on IRC next time.
        Hide
        Werner Guttmann added a comment -

        Afair, Hibernate (we had to have a peek once a few months ago) has implemented an approach where they only need one query. Might be worth the time to educate oneself ... .

        Show
        Werner Guttmann added a comment - Afair, Hibernate (we had to have a peek once a few months ago) has implemented an approach where they only need one query. Might be worth the time to educate oneself ... .
        Hide
        Wensheng Dou added a comment -

        Hi Ralf,

        yes, the solution in the patch is a little wierd. In current implementation, in the first loading, even though we can know the correct class name, but there is not a method to know the fields in the correct class yet.

        We may should consider:
        1. extracting values from result set into sqlinfo. So we can return the results.
        2. a solution to know the fields for the correct class. I think this will relate to SQLEngine and one SQLStatementLoad for the base class of an extends hierarchy.

        I think 1 or 2 will resolve the problem, maybe 2 is better.

        Show
        Wensheng Dou added a comment - Hi Ralf, yes, the solution in the patch is a little wierd. In current implementation, in the first loading, even though we can know the correct class name, but there is not a method to know the fields in the correct class yet. We may should consider: 1. extracting values from result set into sqlinfo. So we can return the results. 2. a solution to know the fields for the correct class. I think this will relate to SQLEngine and one SQLStatementLoad for the base class of an extends hierarchy. I think 1 or 2 will resolve the problem, maybe 2 is better.
        Hide
        Wensheng Dou added a comment -

        In this patch, I'll try to get the fields of concrete class.
        This patch includes the changes in the patch for JIRA-3148.

        Show
        Wensheng Dou added a comment - In this patch, I'll try to get the fields of concrete class. This patch includes the changes in the patch for JIRA-3148.
        Hide
        Ralf Joachim added a comment -

        Could you please update patch after commit of 3148?

        Show
        Ralf Joachim added a comment - Could you please update patch after commit of 3148?
        Hide
        Wensheng Dou added a comment -

        New patch after Jira-3148.

        Show
        Wensheng Dou added a comment - New patch after Jira-3148.
        Hide
        Ralf Joachim added a comment -

        Patch committed as is.

        Show
        Ralf Joachim added a comment - Patch committed as is.

          People

          • Assignee:
            Wensheng Dou
            Reporter:
            Wensheng Dou
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: