https://github.com/kevinmichaelchen/datastore-chicken-and-egg
Chicken and egg problem with Google Cloud Datastore + hierarchical keys
https://github.com/kevinmichaelchen/datastore-chicken-and-egg
Last synced: 3 months ago
JSON representation
Chicken and egg problem with Google Cloud Datastore + hierarchical keys
- Host: GitHub
- URL: https://github.com/kevinmichaelchen/datastore-chicken-and-egg
- Owner: kevinmichaelchen
- Created: 2019-03-25T19:45:44.000Z (about 6 years ago)
- Default Branch: master
- Last Pushed: 2019-04-17T19:42:45.000Z (about 6 years ago)
- Last Synced: 2025-02-23T22:43:39.071Z (3 months ago)
- Language: Go
- Size: 17.6 KB
- Stars: 0
- Watchers: 2
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
## How to run
### In one tab, run
```bash
# Clear DB
rm ~/.config/gcloud/emulators/datastore/WEB-INF/appengine-generated/local_db.bin
# Start DB
gcloud beta emulators datastore start
```
### In another tab, run
```bash
# Set environment so we know what Project ID to use
eval "$(gcloud beta emulators datastore env-init)"
go run *.go
```
## What does this show
If we use `goodKey`, we see this printed:
```
GET RESULT = Folder[ID=2, ParentID=1]
```
If we use `badKey`, we get the error `datastore: no such entity`.
Basically, there's a chicken and egg problem.
Imagine a file system.
Say we're just dealing with folders.
Say we want to lookup a folder by its key.
Its "key" comprises both the folder ID
and the folder's parent ID...
But how do we know the folder's parent ID
before looking up the folder itself?
## Conclusion
Instead of making the parent key the node's parent,
maybe we can use the root folder ID as the parent key
for every node in that true.
That way, we still get to use a common ancestor
for transactional queries and get the advantages of small entity groups.