Hi John, I have tested the methods in 1.1.9 and can confirm they now return the column names & types in a consistent order.
Thanks for the quick fix and best regards Jan -----Original Message----- From: K. John Wu [mailto:[email protected]] Sent: Friday, July 16, 2010 5:46 AM To: FastBit Users Cc: Jan Steemann Subject: Re: [FastBit-users] column orders: dump() & dumpNames() vs. columnTypes() & columNames() Hi, Jan, Just posted the latest FastBit source code as version ibis1.1.9 at <https://codeforge.lbl.gov/frs/shownotes.php?release_id=182>. It should output column names in the same order among various functions now. Please give it a try when you get a chance. Thanks. John On 7/13/2010 12:49 PM, Jan Steemann wrote: > Hi John, > > I think there is a slightly confusing issue with how result columns are > accessible by the public methods in the ibis::table C++ API. > > In my case, I was issueing a SELECT as follows: > SELECT int,AVG(double),COUNT(*) WHERE 1=1 > > "int" and "double" are colum names for columns that have an int and a double > data type. > > > When executing the select with the following code, the results are also ok: > > ibis::part* database=NULL; > ibis::table* table=NULL; > ibis::table* select=NULL; > > database=new ibis::part("/tmp",true); > table=ibis::table::create(*database); > select=table->select("int,AVG(double),COUNT(*)","1=1"); > > select->dumpNames(std::cout,","); > select->dump(std::cout,","); > > > Both dumpNames() and dump() return the columns in the order specified in the > select. > The column names returned by dumpNames() are as expected: int,avg2,count3 > > So far, so good. > > However, when iterating over the column names using select->columNames(), the > column names are: avg2, count3, int. > This order is not the same as the order that dumpNames() returned. > > When trying to access the result set's column types using > select->columnTypes(), the column types are: double, int, int. > Again, this is not what is present in the result of dump() or dumpNames(), > however, it matches the order of columnNames(). > > Obviously, the aggregate column (avg2) is moved to the front of the list. > This also happens for other aggregators that change column types. > > > I think the reason is the different implementation of the accessor methods in > bord.cpp. Some of the methods access the columns in order as defined in the > "columns" property, some methods use the "colorder" property if it is > populated: > > > columnTypes() always returns the columns in an order defined by the "columns" > property: > > ibis::table::typeList ibis::bord::columnTypes() const { > ibis::table::typeList res(mypart.nColumns()); > for (uint32_t i = 0; i< mypart.nColumns(); ++ i) { > ibis::column* col = mypart.getColumn(i); // this does access columns > in order of mypart.columns property > res[i] = (col != 0 ? col->type() : ibis::UNKNOWN_TYPE); > } > return res; > } > > The same order is using in columnNames(). > > > dumpNames() however uses the "colorder" property if initialized and "columns" > if not: > > void ibis::bord::part::dumpNames(std::ostream& out, const char* del) const { > if (colorder.empty()) { > for (ibis::part::columnList::const_iterator it = columns.begin(); > it != columns.end(); ++ it) { > if (it != columns.begin()) > out<< del; // this does access columns in order of the > columns property > out<< (*it).first; > } > } > else if (colorder.size() == columns.size()) { > out<< colorder[0]->name(); > for (uint32_t i = 1; i< columns.size(); ++ i) > out<< del<< colorder[i]->name(); // this does access columns > in order of the colorder property > } > ... > > > Overall, the results of columnNames() and columnTypes() might have a > different order than the results returned by dumpNames() and dump(). > > I was able to confirm the above parts are actually causing the issue by > hacking ibis::part::getColumn(uint32_t) in part.h. This method is used > internally by columnNames() and columnTypes(): > > inline ibis::column* ibis::part::getColumn(uint32_t ind) const { > // also use colorder if valid > if (!colorder.empty()&& ind<colorder.size()) { > return const_cast<ibis::column*>(colorder[ind]); > } > ... > > > This will make getColumn() use the colorder property as well so it is > consistent with dump() and dumpNames(). > > I don't think the hack is very good as the above method is very frequently > used and also an inline method. > Do you think there is a proper fix for this? > > I hope the whole issue is not a mere misunderstanding from my end. > > Best regards > Jan > > -- > Jan Steemann > Team Manager Development Panel | [email protected] Phone +49 2233 > 7933 752 | Fax +49 2233 7933 788 > > Globalpark AG | Kalscheurener Str. 19a | 50354 Huerth | Germany > Vorstand/Chief Executive Officer (CEO) | Dr. Lorenz Graef > Vorsitzender d. Aufsichtsrats/Chairperson of the Supervisory Board | Dr. > Richard C. Geibel > HRG Amtsgericht Koeln/Entered on Cologne Local Court Commercial Register | > HRB 64032 > > GLOBALPARK - manage what matters | http://www.globalpark.de > > _______________________________________________ > FastBit-users mailing list > [email protected] > https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users _______________________________________________ FastBit-users mailing list [email protected] https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
