On Nov 22, 2007 6:54 AM, Paolo Redaelli <[EMAIL PROTECTED]> wrote: > I assume that you're writing about SQLITE_RESULT_ROW;
yes :-) > I usually put preconditions like that when the underlying function call > primise not to return NULL. I made the assumption that string item would > never be NULL and it could actually be wrong; I'm already adding a > proper check to fix it in trunk. Thank you! > I'm not sure it is really wrong; in fact I'm pretty sure it is right as > SQLite documentation says sqlite3_column_text will return NULL only when > an "sql NULL" is converted to text; Some comments about that: * What about reading an already-existing database? There may be NULLs in there, since the data was not written by an Eiffel program... * In any case, my database *was* written by an Eiffel program (if you are interested: ESE/tutorial/tuf) but no precondition caught me when I tried to insert a NULL. * Oracle treats an empty string and NULL exactly the same way (i.e. an empty String is always returned as NULL). It looks like SQlite3 makes a difference. I don't know the SQL norm very well, but it seems there is a little fuzziness here. > this should never happen in an > Eiffel program because we have preconditions in string_item requiring to > call it only on real string columns. I don't understand what you mean. is_string returns True for a NULL. BTW, so does is_integer... I think there should be another way to know the type of the columns. > BTW, have you got NULL pointers in string_item? Yes, that's what triggered my mail. But I don't see what you seem to think is a problem. The code behaved properly and returned the expected Void :-) Cheers, -- Cyril ADRIAN - http://www.cadrian.net/~cyril Any problem can be solved by another layer of indirection. But that usually will create another problem. -- David Wheeler _______________________________________________ Eiffel-libraries-devel mailing list [email protected] https://mail.gna.org/listinfo/eiffel-libraries-devel
