Re: [iPlanet-JATO] More on ComputedColumn issue

Question

Vladimir--
I'm going to answer this question without doing my full homework on it;
please let me know if I hit the mark or not. If I understand correctly, you
have a problem using a model for both UPDATE and SELECT queries because of a
computed column...correct?
If so, this issue is solved in JATO 1.2. 1.2 has an attribute in the field
descriptor to indicate in which type of queries a field should be used. You
can use this attribute to indicate that a field should only be used for
UPDATE queries, SELECT queries, or whatever combination of query types you
require. You can then define synthetic fields for use only during one of
the query types.
Does this sound useful in fixing your issue? A way around this in JATO 1.1
would be to create separate models for SELECT and UPDATE queries. The
SELECT model could contain all the fields for the joined query, but the
UPDATE model would contain info for only one table. The 1.2 feature simple
allows you to do the same using one model.
Todd
----- Original Message -----
From: "vivanov4114" <vivanov@b...>
Sent: Friday, January 11, 2002 8:12 AM
Subject: [iPlanet-JATO] More on ComputedColumn issue
We have a similar problem with do's ComputedColumn after the
translation as Kostas described in his detailed message #439.
We have JATO/iMT version 1.1. Is the resolution of this problem added
to the version 1.2 (or 1.2.1)?
I've tried to adjust the ModelImpl class based on the .sdo file
(using ComputedColumn attributes) for these fields and failed.
Whether I missed something else, or our situation is a little bit
different.
In our case the dataObject has one Computed Field from one table and
another Computed Field from another table along with joint between
these two tables and third one, and, finally, the whole stuff is
under the repeatable (with static fields bindings to these two
computed fields).
The modelImpl class after the translation (as in the #439) has the
same values "" and "." for ..._NAME and QUALIFIED_..._NAME strings
respectively (for each computed do's field).
I guess that we could meet extra problem with this (for manual
adjustment) because of there is no TableName attribute in .sdo file
for computed field (as well as there is no ColumnName attribute for
computed field). If ComputedColumn attribute (computed field) could
play a role of ColumnName attribute (regular case), what would be an
analog of TableName attribute for computed field?
The bottom line of this is as follows: we have a same
SQLException "Invalid Column Name"
from ResultSetModelBase.updateModel() as Kostas described. It causes
the problem for
RequestHandlingTiledViewBase.executeAutoRetrieving() method that
can't bind the proper Model.
Finally, beginDisplay() method from
pgXXXXPriorityCountTiledView.class throws exception and
jasper compiler brings run-time error (Tomcat 3.2).
Kostas, if this problem still exists for translation of such cases,
could you please post a fragment that fixed you original problem in
addition to the message #439 (just to be sure, that I haven't missed
something important).
Thank you very much in advance.
Vladimir Ivanov,
P. S. I've enclosed the excerption from the .sdo file for this
dataObject below.
Class "SQLObject" ;
Name "doPriorityCount" ;
DataFields {
0 { // first df is a computed column from the first
//table
Class "DataField" ;
Name "dfPriorityDesc" ;
ComputedColumn "MIN
(MOS.PRIORITY.PDESCRIPTION)" ;
1 { // second df is a computed column from the second
// table
Class "DataField" ;
Name "dfPriorityCount" ;
ComputedColumn "COUNT
(ASSIGNEDTASKSWORKQUEUE.PRIORITYID)" ;
2 { // third df is a regular df
Class "DataField" ;
Name "MOS_PRIORITY_PRIORITYID" ;
TableName "MOS.PRIORITY" ; // this attribute
// doesn't exist for ComputedColumn
ColumnName "PRIORITYID" ; // this attribute
// doesn't exist for ComputedColumn
DataCachingEnabled "False" ;
DataCachingDuration "0" ;
DataCachingMaxRows "200" ;
DataObjectType "Select" ;
Tables "MOS.ASSIGNEDTASKSWORKQUEUE,MOS.PRIORITY,MOS.DEAL" ;
SQLDistinct "False" ;
SelectFilter {
"MOS.DEAL.SCENARIORECOMMENDED" ;
"=" ;
"'Y'" ;
"AND" ;
"MOS.DEAL.COPYTYPE" ;
"<>" ;
"'T'" ;
SelectOrder {
"MOS.PRIORITY.PRIORITYID ASC" ;
SelectGroup {
"MOS.PRIORITY.PRIORITYID" ;
EnableEntireTableDelete "False" ;
EnableEntireTableUpdate "False" ;
SQLTextOverrideSelect "Partial" ;
SQLTextOverrideDelete "None" ;
SQLTextSelectJoin "MOS.ASSIGNEDTASKSWORKQUEUE.DEALID =
MOS.DEAL.DEALID
AND MOS.PRIORITY.PRIORITYID <> 0
AND MOS.PRIORITY.PRIORITYID =
MOS.ASSIGNEDTASKSWORKQUEUE.PRIORITYID(+)
AND MOS.ASSIGNEDTASKSWORKQUEUE.TASKSTATUSID
(+) = 1 " ;
For more information about JATO, including download information, pleasevisit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp

Answer 1

Todd,
Sorry for the delay with the answer, I've tried to obtain JATO 1.2
and repeat the project migration to verify whether version 1.2 solves
my problem or not (actually, it is a pilot sub-project).
Unfortunately, I still have no 1.2 version.
Let me try to answer on your question without getting the results
with JATO 1.2. Your explanation sounds like version 1.2 is very close
to solve the problem. Actually, our situation is easier because we
have SELECT object only, not SELECT and UPDATE. For data integrity
the only 'Select' ND's do(s) have been used through the whole
project. The backend communication (update, delete) is provided via
EJB like (entity) Java classes.
My question is: could I define synthetic field with 1.1.1 version. By
the way, word synthetic reflects the possibility to construct the
field under certain SQL circumstances (SELECT, UPDATE, e.g.) or the
possibility to construct a `fake' field (for example,
CountColumn of a do) as well. If the later is true, could you please
give a brief idea how to create this synthetic field.
After the translation in the doPriorityCountModelImpl class we've
got:
public static final String COLUMN_DFPRIORITYDESC="";
public static final String QUALIFIED_COLUMN_DFPRIO
RITYDESC=".";
public static final String COLUMN_DFPRIORITYCOUNT="";
public static final String QUALIFIED_COLUMN_DFPRIO
RITYCOUNT=".";
(see my original post please with details, as well).
If this is not a problem for 1.2 please do not waste your time to fix
it for 1.1.1. I need to repeat my results with the version 1.2 anyway.
We have a number of similar idioms through the project. In this
particular case, the CountColumn that counts the field from another
table may bring problem for manual adjustment (see my original
notes). The whole SQL query is as follows (for this case):
SELECT MIN(MOS.PRIORITY.PDESCRIPTION),
COUNT(ASSIGNEDTASKSWORKQUEUE.PRIORITYID),
MOS.PRIORITY.PRIORITYID
FROM MOS.ASSIGNEDTASKSWORKQUEUE, MOS.PRIORITY, MOS.DEAL
WHERE MOS.DEAL.SCENARIORECOMMENDED = 'Y'
AND MOS.DEAL.COPYTYPE <> 'T'
GROUP BY MOS.PRIORITY.PRIORITYID
ORDER BY MOS.PRIORITY.PRIORITYID ASC
During the pre-handler activity (it is the part of our Object
Framework on the top of Netdynamics Object Framework) system passes
id (and mos.deal.dealid = XXX) to the do (select query). After the
run-time execution of this do the results are displayed on the screen
bind to the repeatable statics.
Thank you very much,
Vladimir
--- In iPlanet-JATO@y..., "Todd Fast" <Todd.Fast@S...> wrote:
Vladimir--
I'm going to answer this question without doing my full homework on it;
please let me know if I hit the mark or not. If I understand correctly, you
have a problem using a model for both UPDATE and SELECT queries because of a
computed column...correct?
If so, this issue is solved in JATO 1.2. 1.2 has an attribute in the field
descriptor to indicate in which type of queries a field should be used. You
can use this attribute to indicate that a field should only be used for
UPDATE queries, SELECT queries, or whatever combination of query types you
require. You can then define synthetic fields for use only during one of
the query types.
Does this sound useful in fixing your issue? A way around this in JATO 1.1
would be to create separate models for SELECT and UPDATE queries. The
SELECT model could contain all the fields for the joined query, but the
UPDATE model would contain info for only one table. The 1.2 feature simple
allows you to do the same using one model.
Todd
----- Original Message -----
From: "vivanov4114" <vivanov@b...>
Sent: Friday, January 11, 2002 8:12 AM
Subject: [iPlanet-JATO] More on ComputedColumn issue
We have a similar problem with do's ComputedColumn after the
translation as Kostas described in his detailed message #439.
We have JATO/iMT version 1.1. Is the resolution of this problem
added
to the version 1.2 (or 1.2.1)?
I've tried to adjust the ModelImpl class based on the .sdo file
(using ComputedColumn attributes) for these fields and failed.
Whether I missed something else, or our situation is a little bit
different.
In our case the dataObject has one Computed Field from one table and
another Computed Field from another table along with joint between
these two tables and third one, and, finally, the whole stuff is
under the repeatable (with static fields bindings to these two
computed fields).
The modelImpl class after the translation (as in the #439) has the
same values "" and "." for ..._NAME and QUALIFIED_..._NAME strings
respectively (for each computed do's field).
I guess that we could meet extra problem with this (for manual
adjustment) because of there is no TableName attribute in .sdo file
for computed field (as well as there is no ColumnName attribute for
computed field). If ComputedColumn attribute (computed field) could
play a role of ColumnName attribute (regular case), what would be an
analog of TableName attribute for computed field?
The bottom line of this is as follows: we have a same
SQLException "Invalid Column Name"
from ResultSetModelBase.updateModel() as Kostas described. It causes
the problem for
RequestHandlingTiledViewBase.executeAutoRetrieving() method that
can't bind the proper Model.
Finally, beginDisplay() method from
pgXXXXPriorityCountTiledView.class throws exception and
jasper compiler brings run-time error (Tomcat 3.2).
Kostas, if this problem still exists for translation of such cases,
could you please post a fragment that fixed you original problem in
addition to the message #439 (just to be sure, that I haven't missed
something important).
Thank you very much in advance.
Vladimir Ivanov,
P. S. I've enclosed the excerption from the .sdo file for this
dataObject below.
Class "SQLObject" ;
Name "doPriorityCount" ;
DataFields {
0 { // first df is a computed column from the first
//table
Class "DataField" ;
Name "dfPriorityDesc" ;...........................................
ComputedColumn "MIN
(MOS.PRIORITY.PDESCRIPTION)" ;............................................
1 { // second df is a computed column from the second
// table
Class "DataField" ;
Name "dfPriorityCount" ;
ComputedColumn "COUNT
(ASSIGNEDTASKSWORKQUEUE.PRIORITYID)" ;
2 { // third df is a regular df
Class "DataField" ;
Name "MOS_PRIORITY_PRIORITYID" ;
TableName "MOS.PRIORITY" ; // this attribute
// doesn't exist for ComputedColumn
ColumnName "PRIORITYID" ; // this attribute
// doesn't exist for ComputedColumn
DataCachingEnabled "False" ;
DataCachingDuration "0" ;
DataCachingMaxRows "200" ;
DataObjectType "Select" ;
Tables "MOS.ASSIGNEDTASKSWORKQUEUE,MOS.PRIORITY,MOS.DEAL" ;
SQLDistinct "False" ;
SelectFilter {
"MOS.DEAL.SCENARIORECOMMENDED" ;
"=" ;
"'Y'" ;
"AND" ;
"MOS.DEAL.COPYTYPE" ;
"<>" ;
"'T'" ;
SelectOrder {
"MOS.PRIORITY.PRIORITYID ASC" ;
SelectGroup {
"MOS.PRIORITY.PRIORITYID" ;
EnableEntireTableDelete "False" ;
EnableEntireTableUpdate "False" ;
SQLTextOverrideSelect "Partial" ;
SQLTextOverrideDelete "None" ;
SQLTextSelectJoin "MOS.ASSIGNEDTASKSWORKQUEUE.DEALID =
MOS.DEAL.DEALID
AND MOS.PRIORITY.PRIORITYID <> 0
AND MOS.PRIORITY.PRIORITYID =
MOS.ASSIGNEDTASKSWORKQUEUE.PRIORITYID(+)
AND
MOS.ASSIGNEDTASKSWORKQUEUE.TASKSTATUSID
(+) = 1 " ;
For more information about JATO, including download information, please
visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp