Re: Proposed change regarding trimming of strings...
Noel Grandin <[email protected]> Fri, 25 Feb 2011 10:05:29 +0200
| Newsgroups | gmane.comp.java.orm.simpleorm |
|---|---|
| Message-ID | <[email protected]> |
--------------090208090103020900020909
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
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 expect 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:
>
>
> 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 = field.convertToDataSetFieldType(value);
> if (field instanceof SFieldString && isNewRow()) { // optionaly &&
> field.isPrimayKey()
> convValue = 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
--------------090208090103020900020909
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<head>
<style type="text/css">
<!--
/* start of attachment style */
.ygrp-photo-title{
clear: both;
font-size: smaller;
height: 15px;
overflow: hidden;
text-align: center;
width: 75px;
}
div.ygrp-photo{
background-position: center;
background-repeat: no-repeat;
background-color: white;
border: 1px solid black;
height: 62px;
width: 62px;
}
div.photo-title
a,
div.photo-title a:active,
div.photo-title a:hover,
div.photo-title a:visited {
text-decoration: none;
}
div.attach-table div.attach-row {
clear: both;
}
div.attach-table div.attach-row div {
float: left;
/* margin: 2px;*/
}
p {
clear: both;
padding: 15px 0 3px 0;
overflow: hidden;
}
div.ygrp-file {
width: 30px;
valign: middle;
}
div.attach-table div.attach-row div div a {
text-decoration: none;
}
div.attach-table div.attach-row div div span {
font-weight: normal;
}
div.ygrp-file-title {
font-weight: bold;
}
/* end of attachment style */
-->
</style>
</head>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Tahoma">Hi<br>
<br>
My personal view is that an ORM layer has no business messing with
my data between the database and me.<br>
<br>
If people choose to use databases that space-fill CHAR fields,
then I'd expect to get space-filled data back when I call
getString().<br>
<br>
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.<br>
<br>
My suggestion is that findReference() and related logic has some
database-specific overrides to trim strings before comparing them.<br>
</font><br>
Regards, Noel Grandin.<br>
<br>
Franck Routier wrote:
<blockquote cite="mid:1297950924.5702.26.camel@franck-laptop"
type="cite">
<span style="display: none;"> </span>
<div id="ygrp-text">
<p>Hi,<br>
<br>
there is a known problem in Simpleorm right now regarding
consistency<br>
when dealing with String:<br>
<br>
- getString(field) will right trim String before returning
them.<br>
Comments in SRecordInstance.getString() suggest that
otherwise there are<br>
problems with some databases and character() (not
varrying) sql<br>
datatype.<br>
<br>
- on the other end, setObject will never trim<br>
<br>
- if you happen to have a foreign key on a String primary
key that<br>
happens to have spaces at the end, findReference won't
work, although<br>
the foreign key is valid in the database...<br>
<br>
I have no simple solution to this. We have to deal with
existing data<br>
and we have to deal with character sql datatype and
inconsistencies<br>
accross databases.<br>
<br>
What I suggest will solve at least a few cases, and
especially one that<br>
bites me: if a record is a new row (not existing in
database) and field<br>
is a SFieldString, then right trim the value.<br>
<br>
What this means is that every String you _insert_ using
Simpleorm will<br>
be right trimmed. Existing data won't be touched, and will
be read just<br>
as before.<br>
Optionaly, I could add a test on the field to trim only if
it is part of<br>
a primary key (who would want to have a primary key ended
with<br>
spaces ??).<br>
<br>
The code would look like this (in
SRecordInstance.setObject) :<br>
<br>
try {<br>
convValue = field.convertToDataSetFieldType(value);<br>
if (field instanceof SFieldString && isNewRow()) {
// optionaly &&<br>
field.isPrimayKey()<br>
convValue = convertToString(convValue);<br>
}<br>
}<br>
<br>
This seems like a workaround, but I'm not sure what the
right solution<br>
would be... What do you think of this ?<br>
<br>
Franck<br>
<br>
</p>
</div>
<!-- end group email -->
</blockquote>
<br><br><br><hr><font size="-2" color=808080>Disclaimer: <a href="http://www.peralex.com/disclaimer.html">http://www.peralex.com/disclaimer.html</a><br><br>
<!-- |**|begin egp html banner|**| -->
<br>
<br>
<!-- |**|end egp html banner|**| -->
<div width="1" style="color: white; clear: both;"/>__._,_.___</div>
<!-- Start Recommendations -->
<!-- End Recommendations -->
<!-- |**|begin egp html banner|**| -->
<img src="http://geo.yahoo.com/serv?s=97476590/grpId=7360226/grpspId=1705006905/msgId=2022/stime=1298621150" width="1" height="1"> <br>
<!-- |**|end egp html banner|**| -->
<!-- |**|begin egp html banner|**| -->
<br>
<div style="font-family: verdana; font-size: 77%; border-top: 1px solid #666; padding: 5px 0;" >
Your email settings: Individual Email|Traditional <br>
<a href="http://groups.yahoo.com/group/SimpleORM/join;_ylc=X3oDMTJmdjNjNDliBF9TAzk3NDc2NTkwBGdycElkAzczNjAyMjYEZ3Jwc3BJZAMxNzA1MDA2OTA1BHNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzEyOTg2MjExNTA-">Change settings via the Web</a> (Yahoo! ID required) <br>
Change settings via email: <a href="mailto:[email protected]?subject=Email Delivery: Digest">Switch delivery to Daily Digest</a> | <a href = "mailto:[email protected]?subject=Change Delivery Format: Fully Featured">Switch to Fully Featured</a> <br>
<a href="http://groups.yahoo.com/group/SimpleORM;_ylc=X3oDMTJkdGZmZGw0BF9TAzk3NDc2NTkwBGdycElkAzczNjAyMjYEZ3Jwc3BJZAMxNzA1MDA2OTA1BHNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMjk4NjIxMTUw">
Visit Your Group
</a> |
<a href="http://docs.yahoo.com/info/terms/">
Yahoo! Groups Terms of Use
</a> |
<a href="mailto:[email protected]?subject=Unsubscribe">
Unsubscribe
</a>
<br>
</div>
<br>
<!-- |**|end egp html banner|**| -->
<div style="color: white; clear: both;"/>__,_._,___</div>
</body>
</html>
--------------090208090103020900020909--