Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [geomesa-users] Moving from geomesa-accumulo1.5-1.0.0-rc.7 to geomesa-1.1.0-rc.2

Hi Ben,

Yes, if you don't specify it will use the default encoding, which is kryo. If you wanted to use e.g. avro, you could use the following input argument to the job:

--geomesa.input. featureEncoding avro

Thanks,

Emilio

On 07/15/2015 12:57 PM, Ben Southall wrote:

Thanks Emilio,

 

I will take a look at the (de)serializers – as you say, the new naming matches the functionality better.

 

When using SchemaCopyJob to update existing indexes to the new format, will the feature encoding also be changed? (i.e. if my current tables have avro encoded features, will the encoding be updated to kryo in the new index?)

 

Thanks again,

 

Ben

 

From: Emilio Lahr-Vivaz [mailto:elahrvivaz@xxxxxxxx]
Sent: Wednesday, July 15, 2015 12:28 PM
To: Geomesa User discussions; Ben Southall
Subject: Re: [geomesa-users] Moving from geomesa-accumulo1.5-1.0.0-rc.7 to geomesa-1.1.0-rc.2

 

Hi Ben,

We don't really have a document of the breaking changes, as most users of geomesa interact with us at the geotools interface level, so they aren't affected. The only change most people would have to make is migrating data to take advantage of new index improvements - that process is outlined here:

https://github.com/locationtech/geomesa/tree/master/geomesa-jobs#updating-existing-data-to-the-latest-index-format

If you're using our serializers directly, then you can take a look at the unit tests for examples. The usage is pretty simple:

https://github.com/locationtech/geomesa/blob/master/geomesa-features/geomesa-feature-kryo/src/test/scala/org/locationtech/geomesa/features/kryo/KryoFeatureSerializerTest.scala

Kryo is the main serialization format we're supporting going forward, although we also have options to use avro or native byte buffers.

As you noticed, we changed the names from encoders to serializers to be clearer about what they are actually doing. We also moved around several packages and modules (as you also noticed).

We'll try to get the geomesa.org links sorted out, thanks bringing that to our attention!

If you have any more questions, or things still aren't clear, please let us know.

Thanks,

Emilio

On 07/15/2015 10:19 AM, Ben Southall wrote:

Hello,

 

I’m attempting to transition some code from a CCRI fork (specifically, tag geomesa-DCB-v3.1) based upon 1.0.0-rc.7 to geomesa-1.1.0-rc.2. It seems that in the interim, there have been a number of breaking changes. Some appear obvious (package name changes), some less so.

 

In particular, my code was making use of 1.5-DBC’s org.locationtech.geomesa.core.data.SimpleFeatureEncoder – has this now been broken into the SimpleFeatureSerializer/Deserializer classes? In fact, the whole feature landscape seems to be more complex than it was in earlier versions.

 

Is there a summary document of the breaking changes available?

 

Thanks very much!

 

Ben

 

p.s. The download instructions on geomesa.org are a bit wonky. The instructions to clone a branch geomesa-accumulo1.5-1.1.0-rc.2 seem to be incorrect. The clone works with the tag geomesa-1.1.0-rc.2.

 

Also, the link to the tar.gz for v1.1.0-rc.2 is broken, and the link to 1.1.0-rc.3-SNAPSHOT contains pom.xml files where the version number is 1.0.0-rc.8.




_______________________________________________
geomesa-users mailing list
geomesa-users@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
http://www.locationtech.org/mailman/listinfo/geomesa-users

 



Back to the top