-
Notifications
You must be signed in to change notification settings - Fork 267
Conversation
core/src/dht/dht_store.rs
Outdated
]), | ||
EavFilter::predicate(move |attr| { | ||
match attr { | ||
Attribute::LinkTag(query_link_type, query_tag) | Attribute::RemovedLink(query_link_type, query_tag) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Highlight: This is where filtering is done based on if a tag is provided (so match both tag and type) or only a type is provided (return all tags of that type)
…oring index information about a given entry. This example uses topics which posts can be associated to and indexed.
… once hdk issue is sorted - this should assert for match of post
@@ -17,11 +17,13 @@ use std::{pin::Pin, sync::Arc, thread}; | |||
pub async fn get_links( | |||
context: Arc<Context>, | |||
address: Address, | |||
tag: String, | |||
link_type: String, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, I guess we also want this to be an Option
link_type: String, | |
link_type: Option<String>, |
so that we could requests all links with the same tag but different types. That would match the get_links
semantic we had in proto, no?
@zippy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So you think we should make link_type
optional as well? I guess this is possible but not sure if it makes sense...
I am also not sure if we should be forcing every link to be tagged. This is how it works currently but I suppose we could let people pass a None
to link_entries
and have the HDK add a sensible default behind the scenes. There are a few usability things to sort out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it makes sense to have no tag, i.e. None
.
It does make sense to have the type optional in the get_links
signature so that we can requests all links with the same tag but from different types.
Imagine a use-case where agents can add all different kinds of comments on entries, each being a link with a tag comment
. But the reason why that comment is a valid statement could differ which would best be modeled by having multiple link types with different validation rules. But for rendering all those comments a UI might not care about why something is a valid comment, not caring for the type but instead requesting any link with the tag comment
independent of the type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great!
But: the changelog is off and I would really love to see a test that shows getting links with a given tag works as expected (when there are multiple links with different tags).
Added the ability to retrieve based on type, tag, type+tag or everything. Also added a test for getting the exact match tag (then there are other links to filter out) in the app spec and rust tests |
CHANGELOG-UNRELEASED.md
Outdated
@@ -6,12 +6,9 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 | |||
|
|||
### Added | |||
|
|||
- Option to show NPM output when pulling deps during `hc test` [PR#1401](https://github.com/holochain/holochain-rust/pull/1401) | |||
- Adds scaffolding/skeleton for a future WASM conductor [#894](https://github.com/holochain/holochain-rust/pull/894) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These lines must stay in! Changelogs from other PRs that got merged before!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll get it right one day 🤦♂️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I have put back the changelog items you removed by mistake, see 40f6df8.
Looks great now!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great. Marking approved, though needs a few updates to docs and comments!
Co-Authored-By: Eric Harris-Braun <[email protected]>
…ain/holochain-rust into add-dynamic-link-tag-core
@@ -41,6 +42,7 @@ impl Default for GetLinksOptions { | |||
pub struct LinksResult { | |||
pub address: Address, | |||
pub headers: Vec<ChainHeader>, | |||
pub tag: String, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realise I'm late to the game here, but now that the link_type
param in get_links
is an Option
, should LinksResult
also include the link type?
PR summary
Depends on #1412
This PR adds tags to links with the following properties:
Works great except introduced some flaky tests which need sorting out before merging. It is ready for review though