Ipfs search #32
Ipfs search #32
Conversation
Makefile
Outdated
| graph codegen | ||
| graph build --network goerli | ||
| graph deploy --product hosted-service empaemanuel/talentlayer-goereli |
There was a problem hiding this comment.
typo in the name "goereli"
There was a problem hiding this comment.
removed from here
schema.graphql
Outdated
| name: "serviceDescriptionSearchRank" | ||
| language: en | ||
| algorithm: proximityRank | ||
| include: [{ entity: "ServiceDescription", fields: [{ name: "title" }, { name: "keywords_raw" }, { name: "about" }] }] |
There was a problem hiding this comment.
what is the cost of adding the about "a potential really large text" here ?
It would probably be better to have only title and keywords searchable together. And potentially the about on his own, what do you think ?
There was a problem hiding this comment.
for now we are limited at only one Schema, so we can't separate it, and can't create another one for another entity
| descriptions: [ReviewDescription!] @derivedFrom(field: "review") | ||
| } | ||
|
|
||
| type ReviewDescription @entity { |
There was a problem hiding this comment.
note: in theory, this entity could be marked as immutable https://medium.com/edge-node-engineering/two-simple-subgraph-performance-improvements-a76c6b3e7eac
But as we plan in the future to have dispute on rating, it's ok to keep it like that
schema.graphql
Outdated
| rateType: BigInt | ||
| description: String | ||
| proposal: Proposal! #Proposals that the description describes. | ||
| createdAt: BigInt |
src/mappings/ipfs-data.ts
Outdated
|
|
||
| let description = getOrCreateServiceDescription(ipfsId) | ||
|
|
||
| description.service = context.getString('id') |
There was a problem hiding this comment.
you would probably need a getOrCreate for each linked entity in case they are not yet created. Don't you have any issues here on goerli ?
There was a problem hiding this comment.
I can use it but it always return a new entity due to open issue. Added comments in code
| handler: handleServiceData | ||
| entities: | ||
| - ServiceDescription | ||
| abis: |
There was a problem hiding this comment.
DO you know why we need abis in this context?
There was a problem hiding this comment.
They are not used by the template but they are yet required by the compiler.
0xRomain
added
the
NEED FIX CODE
src/mappings/ipfs-data.ts
Outdated
|
|
||
| const jsonObject = json.fromBytes(content).toObject(); | ||
|
|
||
| let description = getOrCreateServiceDescription(ipfsId) |
There was a problem hiding this comment.
as load didn't work in this ipfs data file, we can add to the context var a bool saying if we are on a creation or an update and use that rather than the load
There was a problem hiding this comment.
We chose to use cid for ID, meaning it is always a new entity.
schema.graphql
Outdated
| @@ -13,26 +13,54 @@ enum PaymentType { | |||
|
|
|||
| type Service @entity { | |||
| id: ID! # service id | |||
| createdAt: BigInt # timestamp of block creation | |||
| updatedAt: BigInt # timestamp of the last change | |||
| created: BigInt! # timestamp of block creation | |||
| transaction: Transaction @derivedFrom(field: "service") # transaction associated with this service | ||
| proposals: [Proposal!] @derivedFrom(field: "service") # proposals for this service | ||
| platform: Platform # Platform on which service was created | ||
| cid: String |
There was a problem hiding this comment.
Yes, if id is the cid and we need to remove the cid, then we need to store the cid to access the old description that we want to remove. Using service.description does not work since it's derived and loaded on query time.
| } | ||
|
|
||
| type Review @entity { | ||
| id: ID! # review nft id | ||
| createdAt: BigInt # timestamp of block creation |
Changed naming of timestamps and added to review
About the update
Here is how it works:
When an entity such as a service, proposal, review, user, or platform is created by a contract it emits an event with a uri to where the ipfs data is located. The convention of which event contains the uri is currently inconsistent between the different entities which has the consequence that it is a little bit unclear regarding when the data fetching mechanism is initialized. Generally, it is initialized in the event handler receiving the uri.
All data fetched from ipfs are stored as entities called
<ParentEntity>Description, i.e. ServiceDescription, ProposalDescription, ReviewDescription, etc, where the id of the entity is it's ipfs id (cid).Each ParentEntity is linked to its description through a field called
description. Each Description entity is linked to its parent through a field called . Ex. ServiceDescription.service = Service.Keywords
User.skills and Service.keywords are fields that stores a list of Keyword entities. These entities are created based on the information from ipfs, which can be viewed in User.skills_raw and Service.keywords_raw.
There are currently a few issues that need to be resolved.
Resolution
Waiting for the current graph issue to be solved.
graphprotocol/graph-node#4087
Changes that impact others
The graph schema is updated so front-end implementations need to update according to the new schema..