Hey, About nulls, i do agree with you. I'm not shocked to say "NULL <=> <empty string>", as far as i know, it is what Oracle does. The attached patch should fix my issue for categories. Later on, we could check a few things about bundles (more specifically, colValue::write) to make them more consistent.
Thanks, -----Original Message----- From: K. John Wu [mailto:[email protected]] Sent: Tuesday, January 24, 2012 4:30 PM To: Dominique Prunier Cc: FastBit Users Subject: Re: [FastBit-users] ibis::relic::keys performance and CATEGORY columns Hi, Dominique, The intention was to not have NULL values in the results. The query answering function take into account of the null masks to eliminate NULL values. Internally, strings are represented as std::string. The constructor can not usually take a nil pointer. The particular error might due to this problem with passing a nil to std::string constructor. Anyway, there might be an issue if we have a NULL in the answer set. It could be worthwhile to look into this further. The problem with NULL string values is that all three forms you've suggested could be valid string values. Presumably, we could settle on one, say the empty string "". This might be the most reasonable choice as the CSV reader actually will treat empty strings as NULL values. This probably means that other database systems output empty strings for NULL values. John On 1/24/12 12:40 PM, Dominique Prunier wrote: > Hmm, just discovered something bad with the patch. If the key is 0 > (which means NULL), the new ibis::category::selectStrings fails > with "basic_string::_S_construct NULL not valid". The is no clear > convention for what is a null string in FastBit interfaces ("", > NULL, "<NULL>") but i guess an empty string would be the best fit > here, right ? > > Thanks, > >
nulls_as_empty.patch
Description: nulls_as_empty.patch
_______________________________________________ FastBit-users mailing list [email protected] https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
