Re: Case sensitivity problem with primary keys in EOEditingContext.faultForRawRow

On Jul 29, 2006, at 6:40 PM, Chad Leigh wrote:

> On Jul 29, 2006, at 6:31 PM, Sacha Michel Mallais wrote:
>
>> On Jul 29, 2006, at 9:19 AM, Marc Gumpinger wrote:
>>
>>> Now the problem - at least in my case - is, that the dictionary's  
>>> keys are all upper case (here "ID") since that's what the  
>>> database returned. However, the primary key's name in the eomodel  
>>> is all lower case (here "id"). For this simple reason, the entire  
>>> faultForRawRow doesn't work.
>>>
>>> Is there an official solution to this problem?
>>> I mean, it was no effort, to adopt the dictionary correspondingly  
>>> so that the keys also match in case sensitivity. However, due to  
>>> EOFs maturity I'm sure that I either made a mistake or oversaw  
>>> something.
>>
>> I would not call case-sensitivity a problem.  I would call that a  
>> feature.  If you've ever been bitten the other way, you'll know  
>> what I mean.
>
> Since SQL is not case sensitive (and various DBs do various  
> things), EOF shouldn't be either on things that deal with stuff the  
> DB returns.

I think you'll find that EOF disavows SQL as much as possible.  In  
fact, there use to be a flat file adaptor... no SQL in sight.  Also,  
database vendors continue to be notoriously bad at following the SQL  
standard, so EOF _has_ to be as flexible as possible.  Finally, I'd  
rather EOF be more like Java, less like SQL, and that includes case- 
sensitivity in my data structures' operations.

Cheers,


sacha


-- 
Sacha Michel Mallais             Senior Developer / President
Global Village Consulting Inc.   http://www.global-village.net/
PGP Key ID: 7D757B65             AIM: smallais
ObAd: read "Practical WebObjects" <fnord>
http://www.global-village.net/products/practical_webobjects