castor

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. Text File
    patch-C3074-20110710.txt
    10/Jul/11 2:11 AM
    9 kB
    Wensheng Dou
  2. Text File
    patch-C3074-20110717.txt
    17/Jul/11 8:43 AM
    8 kB
    Wensheng Dou
  3. Text File
    patch-C3074-20110718.txt
    17/Jul/11 9:12 PM
    5 kB
    Wensheng Dou

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
Wensheng Dou added a comment -

New patch after Jira-3148.

Show
Wensheng Dou added a comment - New patch after Jira-3148.
Hide
Permalink
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
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: