https://typesense.org logo
Join Slack
Powered by
Thanks for the update. This functionality is high ...
# community-help
m
Thanks for the update. This functionality is high on my wish list, as many of my records would benefit from support for objects, and I am used to this from Elasticsearch. But of course I can wait, and work around this by flattening the data.
k
Do you have arrays inside nested objects that you index into ES?
Also nested array of objects. Majority of the implementation complexity was dealing with nested array of objects.
m
I work in scholarly publishing, but indexing a blog is similar and maybe more familiar. A typical use case is indexing blog posts with their authors. There can be one or more authors, and each other has givenName, familyName, affiliation, and potentially more.
There could be arrays within nested objects if I want to support e.g. multiple affiliations, and these could be an array of nested objects (e.g. affiliation name, affiliation country, etc.), but the basic use case that covers 80-90% is support for objects and arrays of objects, but no arrays within the objects.
k
👍
We might have to just flatten the document on Typesense side before indexing and then unflatten it back during display. We might have to store some kinda metadata that allows us to reverse the flattening.
m
A pragmatic approach not supporting all edge cases would work for me.
k
Would it possible for you to put a sample object here for reference? For e.g. the one involving multiple authors involving affiliations which itself could be nested.
a
Hi @Kishore Nallan @Martin Fenner we would also really non flat objects. Not having this is causing major problems
m
@Kishore Nallan This is an example from an Elasticsearch index, with a nested array of objects (nameIdentifiers), and an array of objects at the top level (subjects, dates, rightsList, descriptions): https://api.datacite.org/application/vnd.datacite.datacite+json/10.6084/m9.figshare.90828
👍 1
k
When you query would you want to query all the keys of a nested structure or would you want to zero in on a set of specific keys? For e.g. would you just want to query 
creators
which is a nested object directly or query as 
creators.name
etc. which refer to primitive types.
m
The latter, so 
creators.name
. This particular query is very common. So queries would be for primitive types. An edge case would be queries for 
creators.givenName
& 
creators.familyName
which Elasticsearch addresses with either nested fields (as you want givenName and familyName to belong to the same creator) or a combined field combining both values. I usually use the latter (this is for an index with more than 20 million records).
k
as you want givenName and familyName to belong to the same creator
Yes, this is one tricky thing to handle when you flatten fields: you don't want to end up matching the first name of one person with last name of another.
a
@Kishore Nallan @Martin Fenner did a Github issue end up being created for this?
k
Yes there is an issue tracking this on GitHub.
a
can you let me have the ID @Kishore Nallan?
k
Open in Slack
PreviousNext
Powered by