MHB Why did we remove multiple document types within an index in ElasticSearch?

  • Thread starter Thread starter shivajikobardan
  • Start date Start date
  • Tags Tags
    Index Multiple
AI Thread Summary
The discussion centers on the limitations of declaring different data types for the same field across various document types within a single index in Lucene. Specifically, if an index named "college" contains document types like "student," "teacher," "administration," and "staff," a field such as "date_of_join" cannot have a "text" data type in one document type and a "date" data type in another. This restriction arises from Lucene's management of field types at the index level, which does not allow for flexibility in defining multiple data types for the same field. The conversation highlights the need for clearer examples to illustrate how Lucene's inverted indexing system operates, as the current explanation may not be sufficient for understanding these constraints. The thread has been temporarily closed for moderation.
shivajikobardan
Messages
637
Reaction score
54
The answer is this-:
Because we can't declare a field of different data types within a same index in different document types.

Say there's an index called "college".
Then there are document types called "student" "teacher" "administration" "staff".
What problem would occur if we allow this?

Books and documentations are saying that if a field called "date_of_join" is given a "text" data type in "student", then we can't give "date_of_join" as "date" data type in "staff".

It says that it's due to the way Lucene is.

This is because of the way Lucene maintains the field types in an index. As Lucene manages fields on an index level, there is no flexibility to declare two fields of different data types in the same index

But this is not clear without an example(of how lucene is storing index). Can you guys clarify this?
I know that lucene stores inverted indexes though. But still I'm not clear.
 
Technology news on Phys.org
Thread closed temporarily for Moderation...
 
Thread 'Is this public key encryption?'
I've tried to intuit public key encryption but never quite managed. But this seems to wrap it up in a bow. This seems to be a very elegant way of transmitting a message publicly that only the sender and receiver can decipher. Is this how PKE works? No, it cant be. In the above case, the requester knows the target's "secret" key - because they have his ID, and therefore knows his birthdate.
Back
Top