Interesting. Here are my own thoughts on this:
* Someone needs to point out the obvious fact that Java applications using
index with fields created by ComparableTools will need to adjust their code
in order to read or change those fields. The closest thing I could have
found is https://issues.apache.org/jira/browse/LUCENE-530.
* No need for 3 int64s to store a date. 2 bytes and one short will be too
much. For dates there's the DateTools (currently under work), for which I
think using Boost.Date_Time objects (and helper functions such as to /
from_undelimited_string) is more appropriate, although I have no previous
experience with it, so comments welcome.
* No need to derive from LUCENE_BASE anymore. We're progressively
deprecating that psuedo-class. Also, no need for a virtual destructor if the
only use of this class is through static members.
* Ideally, you'll be reusing more code. The only benefit I see in having it
as a template is for code like:
return ComparableTools<first_type>::valueToString(l.first) +
ComparableTools<second_type>::valueToString(l.second);
Not sure if there's anything to do here, just saying.
* What do you mean by "storing them more efficiently" re. smaller or
unsigned int types? How so?
I guess showing a more complex use cases might make the need for such an
implementation clearer.
Itamar.
-----Original Message-----
From: Isidor Zeuner [mailto:cluc...@quidecco.de]
Sent: Tuesday, September 22, 2009 4:57 AM
To: clucene-developers@lists.sourceforge.net
Subject: [CLucene-dev] RFC: generic storage for numerically based
comparabletypes
Dear CLucene users/developers,
in the comparable-storage branch, I have implemented a template class
ComparableTools to extend NumberTools with the possibility of combining
multiple numerical values into one field. The NumberTools functionality is
mimicked by ComparableTools<int64_t>, but through
ComparableTools<std::pair<first_type,second_type> >, multiple numbers can be
combined while keeping the ordering behavior. This can be used to implement
use cases like dates (std::pair<std::pair<int64_t,int64_t>,int64_t> with
first.first being the year, first.second the month and second the day of the
month), but is not limited to that.
Thoughts:
* provide specializations for smaller or unsigned integer types,
storing them more efficiently
* provide support for boost::fusion types to allow more convenient
usage of large n-tuples
Through the generic mapping of the pure ordering trait for n-tuples into
CLucene, I also hope to gain some insights on the mapping of other
mathematical traits into CLucene, for example to allow GIS querying.
As always, comments are highly appreciated.
Best regards,
Isidor
----------------------------------------------------------------------------
--
Come build with us! The BlackBerry® Developer Conference in SF, CA is
the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf _______________________________________________
CLucene-developers mailing list
CLucene-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clucene-developers
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
CLucene-developers mailing list
CLucene-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clucene-developers
