BillyDong

I believe this check may be somewhat unreasonable. For instance, if the frontend request content is constructed into a new object, even with identical data, the serialized results might differ...

@PSeitz If there are two other fields of string type, defined as STRING | STORED | FAST, is it necessary to traverse all documents to achieve a max aggregation grouped...

@PSeitz Sorry, let me clarify. I have three fields: f1, f2, and f3. f1 and f2 are string fields, while f3 is a numeric field. What I want is to...

@fulmicoton I’m currently using NgramTokenizer::new(3, 3, false) for the subject field. My use case involves emails in various mainstream languages worldwide (e.g., English, Chinese, Japanese, etc.), often mixed within a...

@mdecimus thanks, I'll try it

To clarify, it seems that after modifying a document, it cannot be deleted. The modification is done by first calling delete_query, then add_document, and finally commit.

```rust #[tokio::test] async fn test2() { use tantivy::schema::{FAST, INDEXED, STORED, STRING}; let mut builder = Schema::builder(); let a = builder.add_u64_field("a", INDEXED | FAST); let b = builder.add_text_field("b", STRING | STORED...

@PSeitz Sorry, I sent a text example because I later realized they behave the same. This example is about these two fields: ```rust let a = builder.add_u64_field("a", INDEXED | FAST);...

```rust #[tokio::test] async fn test2() { use tantivy::schema::{FAST, INDEXED, STORED, STRING}; let mut builder = Schema::builder(); let a = builder.add_u64_field("a", INDEXED | FAST); let b = builder.add_text_field("b", STRING | STORED...

@wolfgarbe Cool，and any plans to add an n-gram tokenizer so that segmentation can be performed on any text?