0.90.8 released

Elasticsearch 0.90.8 was just released. New features include an API for
cluster stats and a "simple" query string function that is more accessible
to end users.

Download and release info: http://www.elasticsearch.org/downloads/0-90-8/

Blog: http://www.elasticsearch.org/blog/0-90-8-released/

Feedback appreciated as always!

Kevin

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAB1XBh_CZs0%2BtG9%3DR72%3D2yznUg1DWzSz8caX8w3k%2BBK1w-s%3Daw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

One more breaking change (this compiled cleanly on 9.90.3):

compile:
[echo] debug support = true
[javac] Compiling 79 source files to /Users/brian/proj/build/classes
[javac]
/Users/brian/proj/src/java/com/acme/database/FieldMapping.java:240:
incompatible types
[javac] found :
org.elasticsearch.common.collect.ImmutableOpenMap<java.lang.String,org.elasticsearch.cluster.metadata.MappingMetaData>
[javac] required:
java.util.Map<java.lang.String,org.elasticsearch.cluster.metadata.MappingMetaData>
[javac] Map<String, MappingMetaData> mp =
indexMetaData.getMappings();
[javac] ^
[javac] 1 error

Just started to dive into the 0.90.8 upgrade. Existing code excerpt:

private IndexMetaData indexMetaData = null;
...
Map<String, MappingMetaData> mp = indexMetaData.getMappings();

A lot of times, the breaking change list doesn't include the Java code
changes. I suppose what would be really nice would be a corresponding link
to the on-line Javadoc for each version to gain a quick peek during
upgrade-base code migrations. Thanks!

Brian

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/574dc6a2-df06-44bb-b93b-5f6daa7347a8%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Online Javadoc? Is there such a unicorn? :slight_smile:

I find the issues on Github to be more complete, but even though, some
changes are not properly tagged:

Luckily, most breaking code changes are easy to fix.

Cheers,

Ivan

On Thu, Dec 19, 2013 at 11:54 AM, InquiringMind brian.from.fl@gmail.comwrote:

One more breaking change (this compiled cleanly on 9.90.3):

compile:
[echo] debug support = true
[javac] Compiling 79 source files to /Users/brian/proj/build/classes
[javac]
/Users/brian/proj/src/java/com/acme/database/FieldMapping.java:240:
incompatible types
[javac] found :
org.elasticsearch.common.collect.ImmutableOpenMap<java.lang.String,org.elasticsearch.cluster.metadata.MappingMetaData>
[javac] required:
java.util.Map<java.lang.String,org.elasticsearch.cluster.metadata.MappingMetaData>
[javac] Map<String, MappingMetaData> mp =
indexMetaData.getMappings();
[javac]
^
[javac] 1 error

Just started to dive into the 0.90.8 upgrade. Existing code excerpt:

private IndexMetaData indexMetaData = null;
...
Map<String, MappingMetaData> mp = indexMetaData.getMappings();

A lot of times, the breaking change list doesn't include the Java code
changes. I suppose what would be really nice would be a corresponding link
to the on-line Javadoc for each version to gain a quick peek during
upgrade-base code migrations. Thanks!

Brian

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/574dc6a2-df06-44bb-b93b-5f6daa7347a8%40googlegroups.com
.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CALY%3DcQAHM2Yjt5FoYDubNeD5CK5Z9qO70a27MPFSsrdT5bzRyA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

From the ES version numbering scheme, it is impossible to predict
consequences of updates.

Whenever a minor release appears, it may or may not break existing code,
especially in plugins.

So my humble request is to label releases as "feature releases" (with
expected API breakages), "bugfix releases" (without any API change), maybe
also "security releases" (a bugfix release that is of highest priority and
supersedes all previous releases)

Also a problematic point from the perspective of migration planning is the
visibility of changes in the internal structures, most important, the
binary transport protocol and the Lucene version index format. For better
convenience, this should be somehow reflected in the ES versioning
numbering scheme.

I hope for a more transparent release numbering scheme after 1.0.0

Jörg

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHfvG%3DFWoE8GTFau_mwepp%2B2_8unQk5OiYTTtpwTqbwgw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Is Java API in sync with the new features or delayed respect to REST API?

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/e1dc6088-bdaf-4f76-a868-004641c53cb4%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

The REST API uses the Java API underneath, so any changes to the REST API
should appear in the Java API.

--
Ivan

On Thu, Dec 19, 2013 at 12:16 PM, Adolfo Rodriguez pellyadolfo@yahoo.eswrote:

Is Java API in sync with the new features or delayed respect to REST API?

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/e1dc6088-bdaf-4f76-a868-004641c53cb4%40googlegroups.com
.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CALY%3DcQDWd8LROdrg6bX5j1mXp1zdQo1MRaCan1XCV%2BZyCcp5%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

On Thu, Dec 19, 2013 at 3:15 PM, joergprante@gmail.com <
joergprante@gmail.com> wrote:

From the ES version numbering scheme, it is impossible to predict
consequences of updates.

Whenever a minor release appears, it may or may not break existing code,
especially in plugins.

So my humble request is to label releases as "feature releases" (with
expected API breakages), "bugfix releases" (without any API change), maybe
also "security releases" (a bugfix release that is of highest priority and
supersedes all previous releases)

Also a problematic point from the perspective of migration planning is the
visibility of changes in the internal structures, most important, the
binary transport protocol and the Lucene version index format. For better
convenience, this should be somehow reflected in the ES versioning
numbering scheme.

I hope for a more transparent release numbering scheme after 1.0.0

I wonder if Elasticsearch could use semver, at least from the perspective
of the non-beta portions of the rest api. Personally I don't have the same
feelings about the rest API but understand the argument. I need rolling
upgrades to work though.

Nik

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAPmjWd0uACAZFXi6wvjzaU4tUuSvoEUvytezmueVxQzWW1chYg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Ivan,

Online Javadoc? Is there such a unicorn? :slight_smile:

Hahaha! Yes, there are some older versions (19.X, and also 20.1 Beta) but
nothing later. I don't use them for the actual descriptive writeup (which
is usually quite barren), but find them very useful to check class and
method names during migrations. And then, what's missing from the Javadoc
is usually filled in very nicely by the excellent and helpful ES folks such
as yourself, so it always ends well for me!

I find the issues on Github to be more complete, but even though, some
changes are not properly tagged:

Issues · elastic/elasticsearch · GitHubhttps://github.com/elasticsearch/elasticsearch/issues?direction=desc&labels=v0.90.8%2Cbreaking&milestone=&page=1&sort=updated&state=closed

At
https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/cluster/node/DiscoveryNodes.java

I found this useful example of iterating across the ImmutableOpenMap class:

public DiscoveryNode findByAddress(TransportAddress address) {
    for (ObjectCursor<DiscoveryNode> cursor : nodes.values()) {
        DiscoveryNode node = cursor.value;
        if (node.address().equals(address)) {
            return node;
        }
    }
    return null;
}

Luckily, most breaking code changes are easy to fix.

Indeed, this was the case. Only one of my Java source files that use ES
(out of 110) needed to be modified. Found some snippets on github to help
with the migration. Next is to verify that it actually works, now that it
compiles. Here's my full svn diff:

import org.elasticsearch.cluster.metadata.IndexMetaData;
import org.elasticsearch.cluster.metadata.MappingMetaData;
+import org.elasticsearch.common.collect.ImmutableOpenMap;
+import org.elasticsearch.common.hppc.cursors.ObjectCursor;
import org.elasticsearch.common.xcontent.XContentBuilder;

import com.cequint.nameid.database.sort.SortSchema;
@@ -237,7 +239,7 @@
currentIndex = indexMetaData.getIndex();
indices.add(currentIndex);

  • Map<String, MappingMetaData> mp = indexMetaData.getMappings();
  • ImmutableOpenMap<String, MappingMetaData> mp =
    indexMetaData.getMappings();

    /* For all top-level field mappings */
    String indexTypeName = null;
    @@ -249,14 +251,15 @@
    String fieldSubType = null;

    /* Iterate across all types */

  • for (Map.Entry<String, MappingMetaData> typeCursor : mp.entrySet())
  • for (ObjectCursor typeCursor : mp.values())
    {
  •  indexTypeName = typeCursor.getKey();
    
  •  MappingMetaData mmd = typeCursor.value;
    
  •  indexTypeName = mmd.type();
    
     try
     {
    
  •    for (Map.Entry<String, Object> propsCursor : typeCursor.getValue()
    
  •        .getSourceAsMap().entrySet())
    
  •    for (Map.Entry<String, Object> propsCursor : mmd.getSourceAsMap()
    
  •        .entrySet())
    

Regards,
Brian

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/b9c84d33-4d2f-422e-9c2f-a4c0661a263a%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

FYI here is ES 1.0.0.Beta2 Javadoc as of 8 Nov 2013

http://xbib.org/elasticsearch/1.0.0.Beta2-SNAPSHOT/project-reports.html

Jörg

On Thu, Dec 19, 2013 at 10:06 PM, InquiringMind brian.from.fl@gmail.comwrote:

Ivan,

Online Javadoc? Is there such a unicorn? :slight_smile:

Hahaha! Yes, there are some older versions (19.X, and also 20.1 Beta) but
nothing later. I don't use them for the actual descriptive writeup (which
is usually quite barren), but find them very useful to check class and
method names during migrations.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoErVzzcPCO_gMhqBcc%3DQqvcFWKedV1%2B%3D9j%3DTaG9hUKLsg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Thanks so much, Jörg!

Or, as my favorite customer from my previous company would say, Kiitos!
(The only Finnish I know :slight_smile:

Brian

On Thursday, December 19, 2013 4:52:54 PM UTC-5, Jörg Prante wrote:

FYI here is ES 1.0.0.Beta2 Javadoc as of 8 Nov 2013

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/86fc3c86-2f30-416f-9ac3-b9e069e0364f%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.