-
-
Notifications
You must be signed in to change notification settings - Fork 33
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
Ancestor property contains incorrect data #352
Comments
Could you clarify this issue? As far as I can tell, each of the three returned ids corresponds to an area that exists in the production database:
It is a bit odd that the three are in a single comma separated string. |
If you look at the exported data, here is an example: https://github.com/OpenBeta/openbeta-export/tree/production/usa/alabama/bucks_pocket Searching on any of those ancestor ids brings up the following: You can see there are not actual hits, besides in the ancestor field. These do not point to the _id field of an area like the children do. With this data there is no way for me to link an ancestor to a sub area |
There was a discussion here: https://discord.com/channels/815145484003967026/815490505143484427/1144641711209971756 |
Ah, I see! It's just a bug in exported data. I suspect that the ancestor property already has the ID one would actually want and it's the other IDs that have a bug. The export script is here: https://github.com/OpenBeta/openbeta-graphql/blob/develop/src/db/export/json/index.ts and can be invoked with something like |
yeah that could be the case, but the _id and child fields in the export data match, whereas the ancestor does not. So either ancestor is wrong or both _id and children are wrong |
Is there a workaround for converting the id seen in ancestor ( |
@musoke do you happen to know of a workaround to convert UUID to ObjectId? Not super familiar with |
As mentioned in the Discord chat, they are two different fields in the DB, therefore we can't simply convert _id to query GetUSA {
area(uuid: "1db1e8ba-a40e-587c-88a4-64f5ea814b8e") {
areaName
children {
id
areaName
metadata {
areaId
}
}
}
} result (truncated to save space) {
"data": {
"area": {
"areaName": "USA",
"children": [
{
"id": "63689d10e80bff5a994f159a", // We only store this id field in the db. The rest is populated during the query.
"areaName": "Alabama",
"metadata": {
"areaId": "60bc2823-f54f-59fa-9443-f61a87765009"
}
},
{
"id": "63689d10e80bff5a994f1667",
"areaName": "Arkansas",
"metadata": {
"areaId": "b33d5a8f-4494-55c0-a863-049dce4065d9"
}
}
]}}
} When inserting new areas, the parent's
The proper fix is described in #109. @ClimbFlyCamp can you insert area data as is and do a join in your db queries?
It allows us to use regular expressions to test relationships such as is this area under Colorado? or does this area share the ancestor as crag Y? (Model tree structures with materialized paths) |
@vnugent: Thanks for the helpful info, but still had one question. When looking at the
I was going to join on the Any insight here? |
Looking at the ancestor property on an area I see the following:
These ids do not correlate to any ids inside of the data. Think these should be converted to a similar model that the children field follows:
The children field correctly points to
_id
of the sub area, while theancestors
field is incorrect. There is no way to currently match an ancestor to a sub areaThe text was updated successfully, but these errors were encountered: