Type inference on anonymous objects

[gmarz]

Currently, if an anonymous object is indexed without specifying a type:

client.Index(new { foo = "bar" }, i => i.Index("foo"));

the type is inferred as <>f__anonymoustype0`1

Should we throw an exception instead?

[russcam]

All anonymous type type names start with <> (along with a few other characteristics).

Should we infer type to be object?

[gmarz]

All anonymous type type names start with <> (along with a few other characteristics).

Right, but it seems weird to use that name as a type name in ES.

object is better, and technically follows suit with our inference rules...but it still seems a little unassuming to me.

Also, another potential issue- when an index isn't specified:

client.Index(new { foo = "bar" });

or

client.Index(new Foo { Foo = "bar" });

The index isn't inferred and we get an exception when dispatching the call ("not enough information"). Shouldn't we be falling back to the default index?

[russcam]

I think making the assumption that anonymous types are of type object is reasonable since one general usage is to pass them to methods that accept a parameter of type object e.g. MVC routing, html attributes on HtmlHelper methods.

As for the other issue - yes, I think we should be using the default index here as per NEST 1.x 👍

[russcam]

NEST 1.x uses the anonymous type name e.g.

<>f__anonymoustype0`1

so 2.x is consistent with 1.x right now

[russcam]

Throw exception on known invalid type and index names

[russcam]

issue #9059 on input validation rules for Elasticsearch is still open in regards to valid and invalid characters in directory/filenames.

From source, Elasticsearch does not allow the following characters in a file name i.e. index name currently

'\\', '/', '*', '?', '"', '<', '>', '|', ' ', ','

and there are also some checks for invalid characters in type names

if (mapper.type().length() == 0) {
    throw new InvalidTypeNameException("mapping type name is empty");
}
if (mapper.type().length() > 255) {
    throw new InvalidTypeNameException("mapping type name [" + mapper.type() + "] is too long; limit is length 255 but was [" + mapper.type().length() + "]");
}
if (mapper.type().charAt(0) == '_') {
    throw new InvalidTypeNameException("mapping type name [" + mapper.type() + "] can't start with '_'");
}
if (mapper.type().contains("#")) {
    throw new InvalidTypeNameException("mapping type name [" + mapper.type() + "] should not include '#' in it");
}
if (mapper.type().contains(",")) {
    throw new InvalidTypeNameException("mapping type name [" + mapper.type() + "] should not include ',' in it");
}
if (mapper.type().equals(mapper.parentFieldMapper().type())) {
    throw new IllegalArgumentException("The [_parent.type] option can't point to the same type");
}
if (typeNameStartsWithIllegalDot(mapper)) {
    throw new IllegalArgumentException("mapping type name [" + mapper.type() + "] must not start with a '.'");
}

But given that the issue on validation is still open and being discussed, I'm suggesting we keep the current behaviour and close this issue for the time being. The exception messages that are returned have a clear description of what the problem is.

Thoughts, @gmarz and @Mpdreamz ?

[gmarz]

+1 I think we can close this