[iPlanet-JATO] More on ComputedColumn issue
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" <<a href="/group/SunONE-JATO/post?protectID=081176018237078190215218213140229089163 211175178209171188199">vivanov@b...</a>>
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:
> <a href="http://developer.iplanet.com/tech/appserver/framework/index.jsp">http: //developer.iplanet.com/tech/appserver/framework/index.jsp</a>
>
>
>
>
>
>
>
[6804 byte] By [
Guest] at [2007-11-25 9:35:33]
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 <a href="/group/SunONE-JATO/post?protectID=210083235237078198050118178206047166136 158139046209">iPlanet-JATO@y...</a>, "Todd Fast" <<a href="/group/SunONE-JATO/post?protectID=101233080150035167169232031248066208071 048">Todd.Fast@S...</a>> 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" <<a href="/group/SunONE-JATO/post?protectID=081176018237078190215218213036129208"&g t;vivanov@b...</a>>
> 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:
> > <a href="http://developer.iplanet.com/tech/appserver/framework/index.jsp">http: //developer.iplanet.com/tech/appserver/framework/index.jsp</a>
> >
> >
> >
> >
> >
> >
> >
Guest at 2007-7-1 18:37:20 >
