[Pride-users] Re: Extension Descriptor and documentation enhancement

[<jle...@gm...>]

Hello everybody here
Please find attached some answers for a few questions from the past.

> Hi,
> I"m (still) using PriDE quite extensively, and I stumbled upon some 
> issues, which I wanted to communicate.
> 
> 1) I think it should be noted in the javadoc of SQLExpression that the 
> following code is perfectly valid:
>  
>     exp = exp.and("some_colname",
>                   SQLExpression.Operator.BETWEEN,
>                   (Object) new Long[]
>                   {pObj.getLeft(), pObj.getRight()});
Ok, the Javadocs have been improved accordingly.
  
>  I think it would be even better, to add an extra and() and or() method 
>  to avoid this nasty casting of an array to an object.
Hmm. The casting should not be required because a Java array *IS* an object.
Passing a Long array should lead to a unique method identification.

>  2) What are ExtensionDescriptors? They are in the code, but mentioned 
>  nowhere.
Extension descriptors are a relict from PriDE's early days. We didn't dare
ro remove them but don't recommend to use them either. The idea is to extend
an object by an undetermined number of additional optional attributes which
can dynamically be allocated and assigned or removed. These values are stored
in a separate table of key-value-pairs. This approach is conseptually interesting
because it supports real polymorphism on relational databases. However, from
the view of performance and database structure it is a mess.

>  3) I think it would be nice, to have some kind of "native" support of 
>  ORDER BY expressions in PriDE. I need to apply an ORDER BY to statements 
>  very often in my application. I resolved this, by extending the 
>  RecordDescriptor"s getConstraint() method, and appending the appropriate 
>  ORDER BY at every invocation. Maybe something like this could go into 
>  the core of PriDE (I can give you the code, I used).
Yes, would probably be useful and not too difficult. I would suggest that a feature
like this should best fit into SQLExpression. I'm not so shure about adding it to
the RecordDescriptor class because I don't see ORDER BY as being somehow object-type-
related.

What do you think?


>  That"s it for now, thanks for providing such a nice and easy framework.
You're welcome ;-)

Cheers,
Jan