Bugzilla – Full Text Bug Listing
| Summary: | [DB] Audit mapping creates illegal SQL for XRefs | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Eike Stepper <stepper> | ||||||
| Component: | cdo.db | Assignee: | Eike Stepper <stepper> | ||||||
| Status: | CLOSED FIXED | QA Contact: | Eike Stepper <stepper> | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | stefan | ||||||
| Version: | 4.0 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 7 | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Eike Stepper
I removed the superfluous parantheses.
Committed to HEAD.
But I doubt that it will also work for historical views because the table alias would need to be added to the other columns, too:
if (timeStamp == CDORevision.UNSPECIFIED_DATE)
{
...
}
else
{
builder.append(CDODBSchema.ATTRIBUTES_CREATED);
builder.append("<=");
builder.append(timeStamp);
builder.append(" AND ("); //$NON-NLS-1$
builder.append(CDODBSchema.ATTRIBUTES_REVISED); <<<<<<<<<< !!!!
builder.append("=0 OR "); //$NON-NLS-1$
builder.append(CDODBSchema.ATTRIBUTES_REVISED); <<<<<<<<<< !!!!
builder.append(">=");
builder.append(timeStamp);
builder.append(")"); //$NON-NLS-1$
}
The same issue would then apply as well for the branching mapping strategy. What do you think, Stefan?
Created attachment 176107 [details]
xref testcases
To improve quality, I've created two more XRef Testcases - one for the toOne and one for the toMany case.
What I originally intended to write was:
builder.append(mainTableWhere);
instead of
builder.append("a_t." + mainTableWhere);
at AbstractListTableMapping line 510.
Then the brackets would have been ok. Yet, I just realized that this in turn breaks Branching, because CDO_BRANCH is ambiguous - it is part of the attribute table.
To solve this problem in general, I propose to introduce a constant ATTRIBUTE_TABLE_PREFIX (="a_t.") mapping-strategy and use it consistently in all joins.
Additional comment:
Eike, please have a look at the "XXX fails" comments in my testcase. It seems that CDOObjectReference.getSourceReference() always returns null ?! Is this a bug?
> It seems that CDOObjectReference.getSourceReference() always returns null ?! Is this a bug?
Seems so. The classifierRef in the CDOObjectReference points to ecore::EReference rather than xreftest::referencer
Ok, I've found the problem: In QueryIndication I used ref.eClass() instead of ref.getEContainingClass(). Committed to HEAD Note, your check still fails because for some reason we have two instances of the same ref. Can this relate to dynamic packages? Created attachment 176119 [details]
xref testcases v2
Yes you are right. Because of the dynamic model, the EReferences are not the same instance and EReference.equals() does not seem to be able to correctly compare them, either.
I've changed the testcase to an assertEquals for the reference names.
Now all tests are green.
xref testcases committed to HEAD Available in R20110608-1407 |