You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I find myself passing along a document with its id a lot and feel like we should do a better job of making this ergonomic. It could be as simple as collecting an id method on the DocumentType trait, but I'd like to work out any design implications of dropping everything on the one trait.
For any document_ requests, we can then infer the id:
fndocument_update<TDoc>(index:Index<'static>,doc:TDoc){let ty = TDoc::name();let id = doc.id();UpdateRequest{ index, ty, id }}
The problem with this is that if doc.id() is None, then we need to figure out an id for the request. This is where a separate trait with stricter requirements might come in handy:
traitIdentifiable{fnid(&self) -> Cow<str>;}
With the same set of attributes we derive DocumentType + Identifiable, and requests like document_update will require DocumentType + Identifiable. This would be a bigger breaking change, but means we could have DocumentTypes without necessarily being Identifiable. We could use a combination of the two traits, so we might get an id off DocumentType but must get an id off Identifiable.
The text was updated successfully, but these errors were encountered:
We could also add a #[elastic(id)] attribute to a field on the document struct to make it act as an id (conflicts with #[elastic(id = "")] on the struct itself.
The thing I don't like is requiring more work than just #[derive(ElasticType)] before you can start indexing and updating documents, or effectively the same problem, but instead of failing to compile you just get weird results at runtime.
We could check the custom derive for an #[id]somewhere and panic with a useful message if it's not present? And add a generate_id attribute or something to generate an id if the doc simply doesn't have one.
Actually, just having DocumentType::id() -> Option<Cow<str>> and Identifiable::id() -> Cow<str>, and deriving the Identifiable trait when #[elastic(id)] is present should be enough here.
I find myself passing along a document with its id a lot and feel like we should do a better job of making this ergonomic. It could be as simple as collecting an
id
method on theDocumentType
trait, but I'd like to work out any design implications of dropping everything on the one trait.It could look like:
So you could supply an id when deriving
DocumentType
using an attribute:Which generates a
DocumentType
impl like:For any
document_
requests, we can then infer the id:The problem with this is that if
doc.id()
isNone
, then we need to figure out an id for the request. This is where a separate trait with stricter requirements might come in handy:With the same set of attributes we derive
DocumentType + Identifiable
, and requests likedocument_update
will requireDocumentType + Identifiable
. This would be a bigger breaking change, but means we could haveDocumentType
s without necessarily beingIdentifiable
. We could use a combination of the two traits, so we might get an id offDocumentType
but must get an id offIdentifiable
.The text was updated successfully, but these errors were encountered: