Hey John,

I perfectly agree that the best thing for colUInts::write is to accurately 
return the actual values that came in. However, I see that you restored the 
quoting for non null strings: 
-       if (str != 0 && *str != 0)
-           out << str;
+       if (str != 0)
+           out << '"' << str << '"';
Both (quoted or unquoted) works for me since my code support both, it is up to 
you but if we want to return the exact value, we'd have to remove them.

About the C API, my problem is that the function fastbit_result_set_getString 
uses an empty string as the mark of some errors. So when you call 
fastbit_result_set_getString, there is no way to find out if it failed or if 
you got a NULL:
    if (rset == 0)
        return static_cast<const char*>(0);
    if (pos >= rset->strbuf.size())
        return static_cast<const char*>(0);
    try {
        std::string tmp = rset->results->getString(pos);
        rset->strbuf[pos].swap(tmp);
        return rset->strbuf[pos].c_str();
    }
Maybe that should be replaced with:
    if (rset == 0)
        return 0;
    if (pos >= rset->strbuf.size())
        return 0;
    try {
        std::string tmp = rset->results->getString(pos);
        rset->strbuf[pos].swap(tmp);
        return rset->strbuf[pos].c_str();
    }

That being said, if i change my code to accept empty string, it seems to work 
fine.

Thanks,

-----Original Message-----
From: K. John Wu [mailto:[email protected]] 
Sent: Saturday, March 24, 2012 3:46 PM
To: Dominique Prunier
Cc: FastBit Users
Subject: Re: [FastBit-users] Changes in src/colValues.cpp@495 breaks 
ibis::bundle::getUInt for CATEGORY

Just checked in SVN R501.  The details of the changes are given below.

John


On 3/23/12 2:47 PM, Dominique Prunier wrote:
> Hey John,
> 
> I'm testing r500 right now and i have a few issues:
> 
> 1. In category::stringSearch:
>     else if (ind == 1 && dic.size() == 1) { // special case with one value
>       getNullMask(hits); // all valid entries
>     }
> We can't do this shortcut, this is not nulls that make an error but also 
> empty strings (which is what i have in my test case). When i remove these 3 
> lines, it works again

Your are absolutely right.  In fact both special cases need to be
removed.  This has been done now.

> 
> 2. Most of my select distinct (using bundles) that returns empty strings (key 
> 0) on categories were broken. I think this is related to the fact that the 
> bundle used to write "<NULL>" for key 0 instead of "". Unfortunately, in the 
> C API (fastbit_result_set_getString), the empty string is the mark of an 
> error, so there is no way to distinguish them anymore. In this particular 
> case, this is probably the CAPI which is wrong, maybe we should return a null 
> pointer on error instead of an empty string. If i restore the else in 
> colUInts::write (else out << "<NULL>";), my queries works again

Printing out an empty string as "<NULL>" was a total random action on
my part.  One rationale thing is to do would be give back exactly what
was on input, i.e., "".  I am giving this a try now.  Please let me
know how it goes for you.

> 
> 3. This is not really an issue for me, but it seems also that the quoting of 
> string in colUInts::write got removed. I'm perfectly fine with that, i used 
> to try to strip quotes. It actually happened at r468 but my code was checking 
> if the string was quoted or not before trying to remove them, so it didn't 
> break anything.
> 
The problem is somewhat unclear to me.  The C API is using a string
object to hold the strings.  An empty string should return a valid
pointer const char*.  Now that the empty strings are actually printed
as "", we should not have a problem with empty strings in the
std::string objects.  Hopefully the problem will go away.  If it
persists, I will need some details..
_______________________________________________
FastBit-users mailing list
[email protected]
https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users

Reply via email to