[Question] List of index fields (and their respective types)

[nater540]

Howdy! Pardon posting a question to the issues section, but I am hoping that any response I get will also be useful for other developers 👍

Anyway, I am working on a gem for GraphQL that helps you map Chewy index classes to GraphQL types. Unfortunately, I cannot find a clean way of getting all of the declared Chewy index fields (and their respective types)

Currently, this is what I have come up with - and although it works, it feels slightly hacky.

IndexClass.type('named_index').mappings_hash[:named_index]

In this example, named_index would be whatever you named the type when you called define_type, EG:

define_type Puppies.includes(:shibas, :corgis), name: 'puppies' do
end

Is this the (correctly) and only way of getting the field declarations, or did I miss something really vital? As a side question, is there any way to find out if a field is optional/required, and whether or not it is an array?

Thanks!

[pyromaniac]

Unfortunately, there is no way to understand whether it is an array or not in design-time because ES makes no difference and I don't see any reason to add additional restrictions to Chewy.

As for the field data - yeah, you can fetch it with the mappings hash. There is an object fields representation (MyIndex.send(:build_root)), but first of all, the API is subject to change, and, the second, it provides even less data now than mappings_hash

The same with optional/required fields, ES doesn't need such a data. All the fields are actually optional, i.e. can be nils.

[nater540]

@pyromaniac

Unfortunately, there is no way to understand whether it is an array or not in design-time because ES makes no difference and I don't see any reason to add additional restrictions to Chewy.

That makes sense, thank you for clarifying!

As for the field data - yeah, you can fetch it with the mappings hash. There is an object fields representation (MyIndex.send(:build_root)), but first of all, the API is subject to change, and, the second, it provides even less data now than mappings_hash

Is there any chance that I may make a feature request to have an accessor added for the mappings_hash that will not change in future API updates?

The same with optional/required fields, ES doesn't need such a data. All the fields are actually optional, i.e. can be nils.

I figured that was the case.

[pyromaniac]

I have probably misled you: build_root API will change, mappings_hash will stay the same.

[pyromaniac]

I have probably misled you: build_root API will change, mappings_hash will stay the same.

[nater540]

@pyromaniac Awesome, thank you for clarifying!