Hi,
I'm trying to store a VirtualTable object (for the sql view stuff)
in the MetadataMap, everything appears to be working in memory,
but when I try to save, I get this:
<metadata>
<entry key="cachingEnabled">false</entry>
<entry key="JDBC_VIRTUAL_TABLE">org.geotools.jdbc.VirtualTable@anonymised.com</entry>
</metadata>
Looked in the brief map converter and noticed it assumes the map values
will always be strings, so it does a toString().
VirtualTable is a complex object instead... I guess it means I have to
modify FeatureTypeInfo and add the VirtualTable as a new optional field
as opposed to a metadata entry?
The idea of grafting a jdbc specific bit in the FeatureTypeInfo interface does not really make me jump of joy. Alternatives?
Extending the brief map converter to support complex objects as
values I guess, which kind of seems to invalidating the reason
to have a brief converter in the first place, isn't it?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime ha scritto:
The idea of grafting a jdbc specific bit in the FeatureTypeInfo interface does not really make me jump of joy. Alternatives?
Extending the brief map converter to support complex objects as
values I guess, which kind of seems to invalidating the reason
to have a brief converter in the first place, isn't it?
Ah, I see now that MetadataMap has a get(key, Class target)
method using converters. So having a converter between String and
VirtualTable would work.
However it would be nice if the persister went also the other
way, and used converters instead of toString()... or used
MetadataMap.get(key, String.class) which might have a special
handling of the string case (toString() if the converters
don't return anything else)
Sounds better?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
On 10-05-28 10:25 AM, Andrea Aime wrote:
Andrea Aime ha scritto:
The idea of grafting a jdbc specific bit in the FeatureTypeInfo
interface does not really make me jump of joy. Alternatives?
Extending the brief map converter to support complex objects as
values I guess, which kind of seems to invalidating the reason
to have a brief converter in the first place, isn't it?
Ah, I see now that MetadataMap has a get(key, Class target)
method using converters. So having a converter between String and
VirtualTable would work.
However it would be nice if the persister went also the other
way, and used converters instead of toString()... or used
MetadataMap.get(key, String.class) which might have a special
handling of the string case (toString() if the converters
don't return anything else)
Sounds better?
Yeah. We could also try to make the MetadataMap smarter and instead of just blindly trying to convert to a string for every object only convert for "primitives". But if you want to go the converter route that sounds good too.
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
On 10-05-28 10:25 AM, Andrea Aime wrote:
Andrea Aime ha scritto:
The idea of grafting a jdbc specific bit in the FeatureTypeInfo
interface does not really make me jump of joy. Alternatives?
Extending the brief map converter to support complex objects as
values I guess, which kind of seems to invalidating the reason
to have a brief converter in the first place, isn't it?
Ah, I see now that MetadataMap has a get(key, Class target)
method using converters. So having a converter between String and
VirtualTable would work.
However it would be nice if the persister went also the other
way, and used converters instead of toString()... or used
MetadataMap.get(key, String.class) which might have a special
handling of the string case (toString() if the converters
don't return anything else)
Sounds better?
Yeah. We could also try to make the MetadataMap smarter and instead of just blindly trying to convert to a string for every object only convert for "primitives". But if you want to go the converter route that sounds good too.
The downside of using a converter will be that you'll get a property
like thing inside the xml value, which won't look too pretty. Something
like:
<entry key="JDBC_VIRTUAL_TABLE">
query=select a, b, the_geom from ...
geom.the_geom=point,4326
id=a,b
</entry>
I mean, it's valid, but looks out of place 
(well, assuming the xml output and reading preserves newlines, those
are important in a property file format).
Or I can just get a bit creative and make a converter generating
a xml-like dump using DOM manipulation
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.