On 7/4/01 5:29 AM, "Kasper Nielsen" <[EMAIL PROTECTED]> wrote:
> This has been discussed before and everybody has agreed that it should be
> done.
>
> However its a problem since we are only changing the return type (Vector ->
> List) there is no way of deprecating the various functions. As I see it we
> have 2 choices.
>
> 1. Rename all methods to something new and deprecate the old ones.
> The effected methods in BasePeer are
> doSelect(....)
> executeQuery(....)
> getSelectResults(....)
>
> and in your generated Peer are
> doSelect(....)
> doSelectVillageRecords(...)
> populateObjects(...)
> resultSet2Objects(...)
>
> 2. Just change the return type from Vector to List and let peoples compiler
> fail.
I think you should just change them in 2.2 and leave what is in the 2.1
branch. This is generated code, but I was bitten making changes as the
extension object and peers seem to have a great number of imports
for subclasses.
If you make the change from Vector to List, I think it would be wise
to analyze exactly what is required in the current extension mechanism.
Hopefully we could come closer to something where the extension mechanism
isn't massively affected by changes in the pattern of generation.
I have only looked at one class in Scarab, the Activity.java class
in the om package and it contains a number of imports that aren't
used that were placed their by the torque generation system.
If we could have something closer to total regeneration, or a pattern
where the extensions are almost all business logic than I don't think
we have to worry as much. If torque is the persistence layer, than
hopefully its use will become more transparent over time.
I am +1 for the changes if an analysis of the extension mechanism.
As for the client code, I think this can be added to the migration document
and maybe it's something that can be converted for people.
I think these changes are acceptable across major versions, but if
there's anyway torque can be made to work entirely transparently i.e.
any changes in the generation having zero affect on client code. Possibly
coming up with another way of selecting objects that doesn't use criteria
directly. It's something to think about.
>
>
> I would prefer to keep the same syntax even though it means that we are
> _not_ compatible with previous versions (+1 nr 2)
> Anybody can think of other ways to archieve it?
>
>
> - Kasper
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
