Re: Proposed change regarding trimming of strings...
Noel Grandin <[email protected]> Tue, 01 Mar 2011 14:04:58 +0200
| Newsgroups | gmane.comp.java.orm.simpleorm |
|---|---|
| Message-ID | <[email protected]> |
--------------020101000004030403040409 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Disposition: inline Hi Anthony Yes, I see your point, it is a good thing to paper over some of the DB differences. Hmmm, difficult problem. In answer to your question, yes, I have sometimes used null to mean "nobody has captured a value for this yet" and an empty string to mean "yes a value was captured but it was empty". But then, even the father of databases said that he regrets including nulls in SQL, so I don't feel bad about abusing them :-) Regards, Noel. [email protected] wrote: > > > 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 the ORM. > > I think that having two sets of methods, get/set* and get/set*Exact addresses the need for control. Note that the > value actually stored will always be exactly what the db provides or saves to provide that control. > > As to the current behavior of CHAR, it is complicated and database dependent. 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: > > > > > >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>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, > then why build the model in the first place?" > > Disclaimer: http://www.peralex.com/disclaimer.html --------------020101000004030403040409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <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=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> <font face="Tahoma">Hi Anthony<br> <br> Yes, I see your point, it is a good thing to paper over some of the DB differences.<br> <br> Hmmm, difficult problem.<br> <br> In answer to your question, yes, I have sometimes used null to mean "nobody has captured a value for this yet" and an empty string to mean "yes a value was captured but it was empty".<br> <br> But then, even the father of databases said that he regrets including nulls in SQL, so I don't feel bad about abusing them :-)<br> <br> Regards, Noel.<br> </font><br> <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> wrote: <blockquote cite="mid:[email protected]" type="cite"> <span style="display: none;"> </span> <div id="ygrp-text"> <p>Hello Noel,<br> <br> I take your point that you need to have control.<br> <br> 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 the ORM.<br> <br> I think that having two sets of methods, get/set* and get/set*Exact addresses the need for control. Note that the value actually stored will always be exactly what the db provides or saves to provide that control.<br> <br> As to the current behavior of CHAR, it is complicated and database dependent. I do not propose to sort that out much, just provide a trimming version.<br> <br> Regards,<br> <br> Anthony<br> <br> At 06:05 PM 25/02/2011, Noel Grandin wrote:<br> > <br> ><br> >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> ><br> >Regards, Noel Grandin.<br> ><br> >Franck Routier wrote: <br> >>Â <br> >><br> >>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> ><br> ><br> ><br> >----------<br> >Disclaimer: <<a moz-do-not-send="true" href="http://www.peralex.com/disclaimer.html">http://www.peralex.com/disclaimer.html</a>><a moz-do-not-send="true" href="http://www.peralex.com/disclaimer.html">http://www.peralex.com/disclaimer.html</a><br> ><br> ><br> <br> Spreadsheet Detective,<br> Southern Cross Software Queensland Pty Limited<br> 54 Gerler Street, Bardon, Queensland 4065, Australia.<br> <a class="moz-txt-link-abbreviated" href="http://www.SpreadsheetDetective.com">www.SpreadsheetDetective.com</a><br> "If the model seems correct only because the numbers look right, <br> then why build the model in the first place?"<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=2024/stime=1298981141" 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=X3oDMTJmNWtiamFsBF9TAzk3NDc2NTkwBGdycElkAzczNjAyMjYEZ3Jwc3BJZAMxNzA1MDA2OTA1BHNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzEyOTg5ODExNDE-">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=X3oDMTJkMmYwdTF2BF9TAzk3NDc2NTkwBGdycElkAzczNjAyMjYEZ3Jwc3BJZAMxNzA1MDA2OTA1BHNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMjk4OTgxMTQx"> 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> --------------020101000004030403040409--