search

ruflin / Elastica

Elastica is a PHP client for elasticsearch
http://elastica.io/
MIT License
2.26k stars 736 forks source link

Mapping metadata management #810

Open merk opened 9 years ago

merk commented 9 years ago

The only mapping functionality Elastica currently provides is the Type\Mapping class, which is pretty much just a wrapper around the ElasticSearch api.

FOSElasticaBundle has 2 requirements for mapping metadata:

I'd like to propose moving/building this functionality into Elastica - it seems like it'd be a nice to have for most users who need to store index metadata for other operations.

I envisage the API would be similar to how the Doctrine ORM works, with annotation/yml/xml/php sources. It would allow users to have common methods for defining data about data objects in their projects. See https://doctrine-orm.readthedocs.org/en/latest/reference/basic-mapping.html

This spawns an additional conversation that I'll create a new issue for regarding transformations.

merk commented 9 years ago

An example of what FOSElasticaBundle's configuration for a type might look like can be seen here: https://github.com/FriendsOfSymfony/FOSElasticaBundle/blob/master/Tests/Functional/app/Basic/config.yml#L68-96

Note that I do not propose to use the same syntax/method that the bundle uses, but it is the basis of what is required of such a feature.

ruflin commented 8 years ago

@merk Sorry that I never replied on this one. I think a good place for this would probably be Util functions or something similar in Elastica, so we don't mix "core" elasticsearch functionality with functionality on top. Did work on this progress?

merk commented 8 years ago

I agree that this should be separate from the core Mapping features already implemented in Elastica, but I'm not sure on the best approach here, I dont like the annotation or virtual property approach anymore since indexes/types dont behave the same way.

The only thing I've come up with since I posted this was that there should be a directory specified that contains mapping json files that can be written just like you'd be writing them from the ElasticSearch documentation.

We'd then have tools that can write, update or run the mapping commands as required. Maybe a service that can be interrogated about specific indexes for things like serializing objects without explicit mapping.