RE: 2.2 migration - my approach

[Johnny Quazar <qu...@bitblaster.com>]

I think you are right Walt, I've made a mistake thinking switching 
from NumberKey to int would be better than Integer. It relates to my 
other message from yesterday too.

I'd submit an update to the doc, to strongly recommend Integer 
(null/non-null testing) over int, but I'm still working on the 
migration here. Now I'll add reworking this part to my list. Whew. I 
wish the migration suggestions included "You'll be happier if you use 
Integer" somewhere.

While I'm posting, I did get my project to compile without making a 
bunch of logic changes to my code... but had to resort to a bit of 
ugliness which, unless there's a better way, explains to me why 
there's no deprecated methods provided for those of us who dived in 
at 2.1... since a method cannot request the return type, I had to 
change my source to call a new deprecated method name for "get" 
requests:

public NumberKey getBlogId_DEPnumberkey()
{
           logDeprecated();
           Integer idI = new Integer( getBlogId() );
           return new NumberKey( idI.toString() );
}


At 1:24 PM -0800 1/30/03, Walt Armour wrote:
>We ran into the NumberKey/int thing as well.  We are now reattempting our
>migration to Torque 3.0 but the important part is that now we are changing
>the types in our schema XML to give us Integers instead of ints.  You will
>still need to deal with changing NumberKeys to Integers (and StringKeys to
>Strings) but you won't have to worry about null/non-null and you will still
>have a base class (Object) in order to pass around keys if needed.
>
>>  -----Original Message-----
>>  From: Johnny Quazar [mailto:quazar@bitblaster.com]
>>  Sent: Thursday, January 30, 2003 12:41 PM
>>  To: Turbine Users List
>>  Subject: 2.2 migration - my approach
>>
>>
>>  FWIW, I took some false starts and then decided not to make
>>  hundreds(?) of changes to my app to move from NumberKey to int and
>>  from Vector to List, and instead added methods to the new generated
>>  Torque classes for my schema, such as:
>>
>>
>>  public  class Message
>>       extends cc.rnn.nh.om.BaseMessage
>>       implements Persistent
>>  {
>>        private void logDeprecated ()
>>        {
>>           if (TurbineResources.getBoolean("nh.log.deprecated", false))
>>              Log.debug("*** using old methods for Message");
>>        }
>>
>>        public void setBlogId(NumberKey n) throws TorqueException
>>        {
>>           logDeprecated();
>>           setBlogId( Integer.parseInt(n.toString()) );
>>        }
>>
>>
>>  Obviously this eases the transition only by postponing a lot of work
>>  until later, but it seemed the right way to go for me and this
>>  project (I had plenty to do on it before I added "migrate to 2.2" to
>>  the list).
>>
>>  Thoughts or comments?
>>
>>  ---------------------------------------------------------------------
>>  To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
>>  For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org