Support use of @Converter on String field about datanucleus-mongodb HOT 3 CLOSED

Converting a String to a Long is frankly a strange thing to do, @Convert is for allowing otherwise non-persistable things to be persisted by converting to an acceptable type. Clearly it could be possible to support such a thing with effort but I personally won't be doing so. You could contribute this if it is important to you

FYI, to persist you would need to update https://github.com/datanucleus/datanucleus-mongodb/blob/master/src/main/java/org/datanucleus/store/mongodb/fieldmanager/StoreFieldManager.java#L169 and to retrieve you would need to update https://github.com/datanucleus/datanucleus-mongodb/blob/master/src/main/java/org/datanucleus/store/mongodb/fieldmanager/FetchFieldManager.java#L246 but that would be just for String fields. Then you have Long, Short, Integer, Double, etc.

The fields that are supported for converters are "Object" field types (except the primitive wrappers).

from datanucleus-mongodb.

@andyjefferson okay I will check the code, so at the surface now the problem is not with the core or JDO module but rather the mongodb database module?

Yes, in fact it is strange, but there's a concrete use-case for this which is to query local time ranges (not date)
So one could query for a LocalTime within a range of LocalTimes (hence opens, and closes field)

And do, something like:
SELECT FROM mydomain.Hub WHERE this.schedules.contains(sch) && (sch.day == :schDay && sch.opens <= :startTime && sch.closes >= :endTime)

from datanucleus-mongodb.

See https://github.com/andyjefferson/mongodb-55 for updated testcase that strips out irrelevant code. Note that it could be simplified further and just have a class with a String field, rather than embedding a collection of some subtype with a String field!

from datanucleus-mongodb.