Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: include unique in dimensions #558

Closed
wants to merge 1 commit into from
Closed

fix: include unique in dimensions #558

wants to merge 1 commit into from

Conversation

nathanielc
Copy link
Collaborator

Turns out the unique field can contain useful information to query for example a stream id or a did. This change exposes it in dimensions.

Closes AES-402

@nathanielc nathanielc requested a review from PaulLeCam October 8, 2024 17:17
@nathanielc nathanielc requested a review from a team as a code owner October 8, 2024 17:17
@nathanielc nathanielc requested review from JulissaDantes and removed request for a team October 8, 2024 17:17
Copy link

linear bot commented Oct 8, 2024

@nathanielc nathanielc requested a review from samika98 October 8, 2024 17:20
@nathanielc nathanielc temporarily deployed to github-tests-2024 October 8, 2024 17:37 — with GitHub Actions Inactive
+-------+------------+---------------------------------------------------------------+-------------+----------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------+--------------------------------------------+----------------------------------------------------------------------+
| index | event_type | stream_cid | stream_type | controller | dimensions | event_cid | data | previous |
+-------+------------+---------------------------------------------------------------+-------------+----------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------+--------------------------------------------+----------------------------------------------------------------------+
| 0 | Data | bagcqcerahx5i27vqxigdq3xulceu5qv6yzdvxzamfueubsyxam5kmjcpp45q | 3 | did:key:z6Mkk3rtfoKDMMG4zyarNGwCQs44GSQ49pcYKQspHJPXSnVw | [model: "ce0102015512204bf5122f344554c53bde2ebb8cd2b7e3d1600ad631c385a5d7cce23c7785459a", controller: "6469643a6b65793a7a364d6b6b337274666f4b444d4d47347a7961724e4777435173343447535134397063594b517370484a5058536e5677", context: ""] | bagcqcerahx5i27vqxigdq3xulceu5qv6yzdvxzamfueubsyxam5kmjcpp45q | 6e756c6c | [] |
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we have index starting with 1 here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@samika98 The test does not control the index. It simply inserts the events into the store and then queries them backout. Has your change to start from 1 merged? If so then we likely still have a bug somewhere.

Copy link
Contributor

@samika98 samika98 Oct 8, 2024

Choose a reason for hiding this comment

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

yes we can do this in a separate PR. We should only return fields strictly greater than the high-water-mark. We need to think about how the highwatermark relates to the index
https://linear.app/3boxlabs/issue/AES-403/index-should-start-from-1 : Created a linear issue for this, we can probably pick this up after start from 1 merges

.unwrap_or_default(),
),
(
"unique".to_string(),
Copy link
Contributor

@samika98 samika98 Oct 8, 2024

Choose a reason for hiding this comment

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

nit: Should we have a test that shows that we can query over unique?

Copy link
Contributor

@samika98 samika98 Oct 8, 2024

Choose a reason for hiding this comment

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

nit: move unique to consts?

Copy link
Contributor

@samika98 samika98 left a comment

Choose a reason for hiding this comment

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

We have a test which shows that we are including unique in dimension on the conclusion feed. Should we have a test which checks querying over the "unique" in the conclusion feed ?

@nathanielc
Copy link
Collaborator Author

@stbrody Brought up a good point that the value of the unique dimension is already inside the content (i.e. data ) of the event. So the question is do we need both the dimenstion and the raw data? Th dimension makes is straightforward to query over the unique value, which is the purpose of the dimensions? I don't see much down side to including it and since its valuable to include it I think we should. Thoughts?

@stbrody
Copy link
Collaborator

stbrody commented Oct 9, 2024

my inclination would be to leave it out until/unless someone asks for it. Always easier to add in later than to remove. For now I'd err on the side of keeping the API clean and avoid noise if we don't need it.

@stbrody
Copy link
Collaborator

stbrody commented Oct 9, 2024

but I also don't feel that strongly and could easily be swayed

@nathanielc
Copy link
Collaborator Author

After some discussion we decided its not immediately useful to be able to query the unique dimension. We will need a system to be able to query any kind of relation and only set account relations are queryable via the unique dimension. As such exposing unique to be a dimension creates a different path for querying one of the types of relations and not the others. Therefore we are not going to expose unique dimensions until we have a clear use case for it and have designed how relations generally will be queried.

@nathanielc nathanielc closed this Oct 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants