On Sun, Jul 20, 2008 at 5:24 PM, Zeljko Vrba <
zvrba@ifi.uio.no> wrote:
On Sun, Jul 20, 2008 at 02:45:04PM +0200, Istvan Buki wrote:
>
> For example, I use it to implement a join component. It works more or less
> like a join between two database table but here the table records are
> represented by fusion maps and in each map there is a field used to simulate
> the where clause. Using the fusion::at_key<> function on a map makes that
> very easy.
>
This "where" simulation - what does the field contain? A function object? In
that case, which arguments does the function object take? ("Join" is actually
a cartesian product, and "where a.x = b.y" over primary keys is just a special
case of a predicate that creates "natural join".)
join was probably not the best analogy. Here is the core function of my "join" component that will make it more clear.
InMetaData contain, among other things, the type of the input data. More specifically, InMetaData::type is a fusion map describing all the fields of the input data.
CacheMetaData does the same for the cache.
IndexType is the type used as the common field in the input data and the cache. I retrieve the value of this field in the input data and use it to do a lookup in the cache. The result of that lookup will be a sond fusion map that I'll join to the map of the input data. This new map will be the result of the "join" component I will pass along to other components that will apply other transformation.
typename result_of::join< InMetaData, CacheMetaData, IndexType >::type
apply( const typename InMetaData::type &r )
{
typename IndexType::value_type key_value =
fusion::at_key< IndexType >( r ) ;
return fusion::as_map( fusion::join( r, fusion::erase_key< IndexType >( cache_.lookup( key_value ) ) ) ) ;
}
>
> It also makes it very easy to filter out a column in a table with the
> fusion::erase_key<> function.
>
What is erasing keys useful for? Which concrete task does it solve? The
structure already exists in its fullness in memory after it has been loaded
from the file (or am I mistaken there?), so I doubt that it is for runtime
efficiency.
I mean, isn't "filtering out" more expensive than just ignoring the column?
Why do you list this as an advantage?
Take a very simple example. Your input data is a CSV file and you need to create another CSV file from it but with one or more columns removed. Here is the chain of components I would use.
+------------------+ +--------------+ +-------------------+
| input CSV | ---->| filter out |----->| output CSV |
+------------------+ +--------------+ +-------------------+
If the filter component erase the column, I can just give a template parameter to my component to let it know which column to remove.
On the other hand if I work by ignoring what is not needed I need explicitly to tell what I'll copy to the output file which requires more work. In fact it is the base for a more general component that is mapping input fields to output fields either directly or by aggregating the value of several input fields using some function that produce a result which will be written to an output field.
You can achieve the same result using one or the other component but in some cases it is easier to go with the less general solution because it is simpler to code.
BTW, I'm not challenging your choices in any way -- I'm just trying to learn
something on a concrete example.