Skip to content
This repository has been archived by the owner on Feb 3, 2023. It is now read-only.

Get links Count #1568

Merged
merged 66 commits into from
Jul 17, 2019
Merged

Get links Count #1568

merged 66 commits into from
Jul 17, 2019

Conversation

StaticallyTypedAnxiety
Copy link
Contributor

PR summary

Allow the zome developer to be able to get the link count

testing/benchmarking notes

( if any manual testing or benchmarking was/should be done, add notes and/or screenshots here )

followups

( any new tickets/concerns that were discovered or created during this work but aren't in scope for review here )

changelog

Please check one of the following, relating to the CHANGELOG-UNRELEASED.md

  • this is a code change that effects some consumer (e.g. zome developers) of holochain core so it is added to the CHANGELOG-UNRELEASED.md (linked above), with the format - summary of change [PR#1234](https://github.com/holochain/holochain-rust/pull/1234)
  • this is not a code change, or doesn't effect anyone outside holochain core development

@StaticallyTypedAnxiety
Copy link
Contributor Author

StaticallyTypedAnxiety commented Jul 2, 2019

I propose a follow up story in which GetLinks uses the NetworkQuery for the querying of the GetLinks.

Could have been done in here but seems out of scope

@StaticallyTypedAnxiety
Copy link
Contributor Author

Still missing get_by_tag functions but that should be coming soon

@StaticallyTypedAnxiety StaticallyTypedAnxiety changed the title Get links Count [WIP]Get links Count Jul 2, 2019
@StaticallyTypedAnxiety StaticallyTypedAnxiety added the WIP work in progress label Jul 2, 2019
Copy link
Collaborator

@lucksus lucksus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good but I really think we should include a refactoring that merges all these new actions, reducers and futures into just one set of those all queries..

@@ -160,8 +160,11 @@ pub enum Action {
/// Last string is the stringified process unique id of this `hdk::get_links` call.
GetLinks(GetLinksKey),
GetLinksTimeout(GetLinksKey),
GetLinksCount((GetLinksKey, Option<CrudStatus>)),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We discussed merging Get* / RespondGet* to Query / RespondQuery. That would make this PR already smaller as we would need all that cruft including a new future etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about this and just used GetLinks with an enum because one thing I was worried about was the disconnect between what happens on the from the request point of view and the sever point of view. The reason why GetLinksCount was implemented explicitly because following it down the workflow is easy in terms of "new developers" and someone who isn't just new to the system. But I just used an enum as a parameter instead because doesn't over complicate what is happening there.

RespondGet merges and RespondQuery I think is something that should come into play as a later PR imo because some of this stuff can really propagate through a lot of changes making the scope much bigger as it goes.

zippy
zippy previously requested changes Jul 12, 2019
Copy link
Member

@zippy zippy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This all looks great, especially the tests which cover the different cases. But, as per Nico's suggestion, and my rule that when we repeat things (i.e. copy over boilerplate) for the third time then it's time to generalize. So my requested change is to refactor at least the GetLink* and RespondGetLink* actions and futures into just one Query/RespondQuery with an enum as a the payload that holds either the actual Links result or the count.

So much of the code is the same, that it really seems like a refactor is in order here, and also worth it, because I'm guessing that we may want to be able to add some other enum into list.

CHANGELOG-UNRELEASED.md Outdated Show resolved Hide resolved
@@ -851,6 +851,137 @@ scenario('get_links_crud', async (s, t, { alice, bob }) => {
t.equal("deleted",bob_posts_all.Ok.links[1].status);


})

scenario('get_links_crud_count', async (s, t, { alice, bob }) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also need to add this test into app_spec_proc

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought app_spec_proc copies over this from test.js?

app_spec/test/test.js Outdated Show resolved Hide resolved
Copy link
Collaborator

@lucksus lucksus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks way better! I still think we should go all the way only talk about queries in our network actions/reducers as mentioned in my inline comments. Also representing GetLinksCount as its own query seems much cleaner to me.

But the main thing here: the new app-spec test is not passing.

#[derive(Debug, Serialize, Deserialize, PartialEq, DefaultJson, Clone)]
pub enum NetworkQuery {
GetEntry,
GetLinks(String, String),
GetLinks(String, String, Option<CrudStatus>, GetLinksNetworkQuery),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I regard link counts as a different query, instead of a parameter to GetLinks. I think it would be much cleaner to represent it here in that way too: instead of introducing those enums above, why don't we have a GetLinksCount(String, String) specialization here?


//make sure it is equal to 1
t.equal(1,alice_posts_deleted.Ok.count);
t.equal(1,bob_posts_deleted.Ok.count);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RespondGetLinks((QueryEntryData, Vec<(Address, CrudStatus)>, String, String)),
HandleGetLinksResult((Vec<(Address, CrudStatus)>, GetLinksKey)),
RespondGetLinks((QueryEntryData, GetLinksNetworkResult, String, String)),
HandleGetLinksResult((GetLinksNetworkResult, GetLinksKey)),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would love to see these actions and the corresponding action creators and reducers in the network module to not know about links at all and just operate on the generic level of queries.

@lucksus lucksus dismissed zippy’s stale review July 17, 2019 14:17

Checked in with @zippy via chat who is on the go rigth now.

@StaticallyTypedAnxiety StaticallyTypedAnxiety merged commit 3930874 into develop Jul 17, 2019
@zippy zippy deleted the get-links-count branch October 4, 2019 18:30
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants