Lists

Terms and Conditions
Lists hosted on this site
Email the Postmaster
Tips for posting to public mailing lists

Information: WO 5.2 migration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Information: WO 5.2 migration

Subject: Information: WO 5.2 migration
From: Jonathan Rochkind <email@hidden>
Date: Tue, 11 Feb 2003 16:03:44 -0600

I am at the tail end of migrating a large and complex body of code from WO 5.0 to WO 5.2. I thought people might be interested at the handful of challenges I encountered, that to my knowledge aren't mentioned in the Apple delta docs. I didn't stop at 5.1, I went right from 5.0 to 5.2, so I'm not sure which of these changes were actually 5.1 changes.

1. All direct SQL fetches, that is fetches based on raw SQL instead of a model, whether through the EOUtilities.rawRowsForSQL convenience method or lower-level EOF API, now use the Java Long object for numeric data in the result set that used to be returned as Integer. I suppose this is a feature not a bug, but it was somewhat inconvenient to find and fix for the migration.

2. Automatic Boolean conversion in EOF: the EOGenericRecord storedValueForKey method appears to now use reflection to see the return type of the cover method for the attribute in question. For instance, let's say you have a numeric attribute in your entity "someAttribute". If there exists in the Java class for the entity a method signature "public boolean someAttribute()" OR "public Boolean someAttribute()", then storedValueForKey("someAttribute") will return a Boolean value. In WO 5.0, this did not happen. The algorithm used to convert from numeric to boolean seems to be: a value of 1 is true, any other value (including null) is false. Null will never be returned by storedValueForKey in this situation.

This does not seem to be documented anywhere at all. I suppose this is a convenient feature, maybe, but it was without a question my biggest headache in the migration. I had places where such methods existed, causing EOF to now do a numeric-to-Boolean conversion for me, but where I had previously been using a _different_ and _incompatible_ algorithm to convert to Boolean. And other places where, for legacy reasons, one method existed that converted from numeric to boolean, but another method with a different name existed that exposed the raw numeric value. But with storedValueForKey always converting to Boolean for me, the numeric value was no longer available. The only solution in these cases was to change the name of the cover method and/or the attribute, so they were no longer the same, and storedValueForKey wouldn't automatically do a conversion, letting me do the conversion myself however I wanted. This was a big pain in my very large codebase.

3) EODatabaseContext.Delegate signature change: There was an EODatabaseContext Delegate method that previously had the signature: public boolean adaptorChannelShouldEvaluateExpression(Object channel, EOSQLExpression expression)

From 5.0 to 5.2, the signature changed to the (more correct, really): public boolean adaptorChannelShouldEvaluateExpression(EODatabaseChannel channel, EOSQLExpression expression)

It took me way longer than it should have to figure out that my delegate method using the old signature wasn't being called anymore, and that was causing the problem I was seeing.

4) Dynamic Element Binding Validation: In WO 5.2, dynamic elements check for valid bindings upon instantiation, and throw an exception if the bindings are not valid. In WO 5.0, this didn't happen: if the bindings weren't valid, it would probably cause some side effect exception, such as a NullPointer or ClassCast exception, but there was no explicit binding validation on instantiation. As a result, in 5.0, you might have a dynamic element that for some reason never actually gets used (say, it's wrapped in a conditional that's permanently bound to 'false'), and this would not be a problem. But in 5.2, it will keep the entire component from working, throwing an exception upon appendToResponse.

5) 'shared' seems to be a name to avoid using as an EOF attribute name in 5.2. It did not cause a problem in 5.0. The nature of the problem was very mysterious, hard to duplicate, and only showing up in somewhat rare circumstances in 5.2, but I finally isolated it enough to verify that changing the attribute name to something other than 'shared' made the problem go away. Even though I still can't explain exactly the nature of the problem. _______________________________________________ webobjects-dev mailing list | email@hidden Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev Do not post admin requests to the list. They will be ignored.

Prev by Date: Re: locking editing context
Next by Date: Re: Listing of routines and classes
Previous by thread: Re: advice? new file upload API and mime content-type
Next by thread: Re: Information: WO 5.2 migration
Index(es):
- Date
- Thread