[
https://issues.apache.org/jira/browse/LUCENE-7936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16145047#comment-16145047
]
Karl Wright commented on LUCENE-7936:
-------------------------------------
[~ivera], I committed the missing constructor.
I had thought that we eventually could improve the packing of class names.
However, to be a correct implementation, this needs to be built into
SerializableObject fully, since there are a number of objects which decompose
heterogeneously into subobjects. I would therefore want to see the patch
restructured to modify SerializableObject in that way. The problem, of course,
is that you need an object that you instantiate somehow that drives the
serialization and deserialization, and the SerializableObject API is not set up
to use such a thing.
Instead, these are your options:
(1) Have a static table of standard classes and a class-name encoding that
starts with a byte. If the byte is not 0xff, then look up the standard class
from the table. If not, follow the byte with the string encoding we do right
now. Works fine in a static environment, but custom classes are more expensive
to serialize.
(2) Have a non-static "SerializationContext" class that you initialize before
you serialize or deserialize. Then, every write() or deserialization construct
must get the SerializationContext passed as an argument.
SerializationObject.readObject() and SerializationObject.writeObject() must
also receive this parameter. This is a major bit of work, of course, but might
be worth it if you intend to do lots of custom geo classes.
One other comment on code: I notice you throw some RuntimeExceptions. Those
are inappropriate for bad arguments or a bad object state. Use
IllegalArgumentException or IllegalStateException instead in those cases.
Please let me know what you want to do.
> Extend Geoshape interfaces so objects can be copied/serialized
> --------------------------------------------------------------
>
> Key: LUCENE-7936
> URL: https://issues.apache.org/jira/browse/LUCENE-7936
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial3d
> Reporter: Ignacio Vera
> Assignee: Karl Wright
> Fix For: 6.7, master (8.0), 7.1
>
> Attachments: factory.patch, GeoBinaryCodec.patch,
> LUCENE-7936-GeoComplexPolygon.patch, LUCENE-7936.patch, LUCENE-7936.patch,
> LUCENE-7936.patch, LUCENE-7936-test.patch, Spatial4j.patch
>
>
> Hi [[email protected]],
> I would like to propose to extends the GeoShape interfaces to be able to
> copy/serialized the objects. The current status and propose change is as
> following:
> GeoPoint: It can be serialized by using x, y, z
> GeoCircle: It can be serialized by using getCenter() and getRadius() and
> getPlanetModel()
> GeoCompositeShape: It can be serialized by accesing shapes using size() and
> GetShape(int index)
> GeoPath: add methods to the interface getPoints() and getCutoffAngle()
> GeoPolygon: This is the most complicated one as we have different types:
> 1.- GeoCompositePolygon is just a composite
> 2.- GeoConcavePolygon and GeoConvexPolygon: Create a new interface for
> those polygons which exposes the points, holes, internaledges and
> concavity/convexity
> 3.- GeoComplexPolygons: Do nothing, they are too complex to be serialize??
> I am intersested in accesing the discreatization of the polygons into convex
> and concave ones for other reasons as well. I think this should be expose as
> they end result can be used for other use cases.
> Cheers,
> I.
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
