|
OK, I'll give that a try. In principle, however, it doesn't seem right that the use of a converter is dependent on the specification of property meta-data. What if I just want to store that property, not search for it?
The application I'm working on involves storing some fearsomely complex object graphs, but few searchable properties. Having to add a meta-data tag to every property that needs a type converter is going to get mightily tedious. You said that the converter on the property tag is usually not used... does that mean it can be used, if necessary? If not, why does the schema llow it? In this case, you should use the managed-id-converter attribute and set that on the property mappings.
By the way, you can also register generic converters that will handle types such as Joda DateTime. In this case you should set the following settings for the converter (this is not exposed in the schema configuration): compass.converter.mydatetime.type=test.MyDateTimeConverter This will cause your converter to be the default converter for Joda DataTime class. Ah, the registered type converter is perfect, thanks. That's what I wanted to begin with, but couldn't find any such thing in the docs - did I miss something?
Intuitively, though, I still think the way I configured things in the original test case should work, but I'll leave that up to you. The global converter mapping does the job for me. Its basically goes back to the beginning of Compass and its design. The converter applies to the mapping. In Compass, property does not translate to a Resource Property, but the meta-data mapping does.
|
||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Major
Named converter being ignored
The meta-data mapping are the ones that you care about. If you add the meta-data tag, and put the converter on it, then things should work.