Re: Proposed change regarding trimming of strings...

Hello Noel,

I take your point that you need to have control.

However, in practice, nulls, "" and trailing spaces are not useful and can =
cause grief.  Have you ever had a reason to use both nulls and ""s?  It is =
also database dependent, and providing basic DB independence is a goal of t=
he ORM.

I think that having two sets of methods, get/set* and get/set*Exact address=
es the need for control.  Note that the value actually stored will always b=
e exactly what the db provides or saves to provide that control.

As to the current behavior of CHAR, it is complicated and database dependen=
t.  I do not propose to sort that out much, just provide a trimming version=
.

Regards,

Anthony

At 06:05 PM 25/02/2011, Noel Grandin wrote:
>=20=20
>
>Hi
>
>My personal view is that an ORM layer has no business messing with my data=
 between the database and me.
>
>If people choose to use databases that space-fill CHAR fields, then I'd ex=
pect to get space-filled data back when I call getString().
>
>Trimming data on either trip is going to cause very confusing issues where=
 the length of the string is changed during a round-trip to the database.
>
>My suggestion is that findReference() and related logic has some database-=
specific overrides to trim strings before comparing them.
>
>Regards, Noel Grandin.
>
>Franck Routier wrote:=20
>>=C2=20=20
>>
>>Hi,
>>
>>there is a known problem in Simpleorm right now regarding consistency
>>when dealing with String:
>>
>>- getString(field) will right trim String before returning them.
>>Comments in SRecordInstance.getString() suggest that otherwise there are
>>problems with some databases and character() (not varrying) sql
>>datatype.
>>
>>- on the other end, setObject will never trim
>>
>>- if you happen to have a foreign key on a String primary key that
>>happens to have spaces at the end, findReference won't work, although
>>the foreign key is valid in the database...
>>
>>I have no simple solution to this. We have to deal with existing data
>>and we have to deal with character sql datatype and inconsistencies
>>accross databases.
>>
>>What I suggest will solve at least a few cases, and especially one that
>>bites me: if a record is a new row (not existing in database) and field
>>is a SFieldString, then right trim the value.
>>
>>What this means is that every String you _insert_ using Simpleorm will
>>be right trimmed. Existing data won't be touched, and will be read just
>>as before.
>>Optionaly, I could add a test on the field to trim only if it is part of
>>a primary key (who would want to have a primary key ended with
>>spaces ??).
>>
>>The code would look like this (in SRecordInstance.setObject) :
>>
>>try {
>>convValue =3D field.convertToDataSetFieldType(value);
>>if (field instanceof SFieldString && isNewRow()) { // optionaly &&
>>field.isPrimayKey()
>>convValue =3D convertToString(convValue);
>>}
>>}
>>
>>This seems like a workaround, but I'm not sure what the right solution
>>would be... What do you think of this ?
>>
>>Franck
>
>
>
>
>----------
>Disclaimer: <http://www.peralex.com/disclaimer.html>http://www.peralex.com=
/disclaimer.html
>
>


Spreadsheet Detective,
Southern Cross Software Queensland Pty Limited
54 Gerler Street, Bardon, Queensland 4065, Australia.
www.SpreadsheetDetective.com
"If the model seems correct only because the numbers look right,=20
then why build the model in the first place?"



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/SimpleORM/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/SimpleORM/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected]=20
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/