Avoid converting BTreeMap to Vec in TantivyDocument::add_object.

[adamreichold]

For the next breaking release when the immediate issues with 0.22.x are resolved.

[fulmicoton]

@adamreichold it won't compile.

[adamreichold]

@adamreichold it won't compile.

Yes, because a sequence of key-value pairs cannot directly be deserialized from a map. I added a thin wrapper to make that adjustment which avoids the overhead of the associative data structures, but keeps the convenience during deserialization.

[PSeitz]

that seems like a worse API

[adamreichold]

Please expand on worse in what way or rather what you would prefer?

It definitely adds a bit of ceremony for the wrapper type, but it does avoid the unnecessary conversion for example in the unit tests here. Would you prefer some kind of implicit conversion via generics and trait bounds?

[PSeitz]

BTreeMap is a well know data structure for objects, while FlatObject would require some digging on how to convert into it

[fulmicoton]

what about any impl IntoIterator<Item=(String, OwnedValue>)>

[fulmicoton]

I don't quite understand the motivation for this PR. @adamreichold ?

[adamreichold]

I don't quite understand the motivation for this PR. @adamreichold ?

TantivyDocument stores objects as flat vectors of key-value pairs but the API here requires going through BTreeMap only to convert it internally. To me, this seems wasteful and while I do not want to specifically avoid BTreeMap, I would like the API to enable at least one way of using it without the unnecessary intermediate collection.

[PSeitz]

add_object is a convenience function, you can now add anything that implements Value

[adamreichold]

add_object is a convenience function, you can now add anything that implements Value

Agreed. I was somewhat mechanically rebasing my branches and did not review all of the API changes implied by CompactDoc. Closing this one.