Oops, I guess after the first maill, rest of the mails were not sent to dev list.
Regards, Amita On 8/7/07, Adriano Crestani <[EMAIL PROTECTED]> wrote: > > Yes, but I suggest the name columnIndex or just index instead of > columnIdx. > > Regards, > Adriano Crestani > > On 8/6/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote: > > > > Hi Adriano, > > Just to get it clear, at present, result descriptor defn is > > <xsd:complexType name="ResultDescriptor"> > > <xsd:attribute name="columnName" type="xsd:string"/> > > <xsd:attribute name="tableName" type="xsd:string"/> > > <xsd:attribute name="schemaName" type="xsd:string"/> > > <xsd:attribute name="columnType" type="xsd:string"/> > > </xsd:complexType> > > > > So, you are suggesting to add a new attribute, > > <xsd:attribute name="columnIdx" type="xsd:int"/> > > to this? > > > > Regards, > > Amita > > > > On 7/12/07, Adriano Crestani <[EMAIL PROTECTED]> wrote: > > > > > > Yes, Amita, I agree with you there must be a way to define the > > > ResultDescriptor when the user create the command using createCommand > > > method. But instead of define it in a sequence, it could be defined > > > relating > > > the ResultDescriptor with a column index. > > > > > > However, the problem the user came up on JIRA-1355 has nothing to do > > with > > > the way the sql query is created, but with the non previously > knowledge > > of > > > what the query may return. For example, can you tell me what the > follow > > > sql > > > return? > > > > > > "select * from company" > > > > > > I see two cases where the user cannot foreseen the company attributes > > > retrieved on this query: > > > > > > 1 - the company attributes may change on future. > > > 2 - defining the company attributes is not on his charge. > > > > > > On the first case, the user can manually redefine the company > attributes > > > on > > > ResultDescriptor every time it changes. But on the second one, the > user > > > might not be able to know when it changes. > > > > > > The only way to overcome this problem is to leave it with JDBC > metadata. > > > Unfortunately, Oracle JDBC Driver does not provide all necessary > > metadata > > > that DAS needs : ( > > > > > > Regards, > > > Adriano Crestani > > > > > > On 7/12/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi, > > > > Recently there came up a requirement from user (ref. JIRA-1355), > when > > > the > > > > user > > > > was attempting DAS.createCommand(sql) in Oracle. As of today, in RDB > > > DAS, > > > > user > > > > can specify ResultDescriptor using external Config File containing > > > > Commands. > > > > But > > > > there is no provision for user to pass ResultDescriptor for a > Command, > > > > when > > > > it is > > > > created as above (dynamic - without Config File). As, for Oracle and > > > some > > > > other > > > > databases, when database meta data is not sufficient, DAS requires > > user > > > to > > > > supply > > > > ResultDescriptor as a substitute. For taking care of such > situations, > > > DAS > > > > needs to > > > > expose Command.set/getResultDescriptors(List <ResultDescriptor>). > > > > > > > > One rule to be adhered when using this API will be sequencing of > > > > ResultDescriptors > > > > in the input List.The sequence in the List <ResultDescriptor> has to > > be > > > in > > > > sync > > > > with the sequence of parameters in "sql". With this, I guess it will > > be > > > a > > > > really > > > > useful and handy functionality, that RDB DAS needs to consider. > > > > Thoughts? > > > > > > > > Regards, > > > > Amita > > > > > > > > > >
