rewrite
Nate Smith 2023-12-09 15:55:44 -08:00
parent bc843b27cc
commit 673232919b
2 changed files with 41 additions and 0 deletions

View File

@ -46,6 +46,46 @@ from plant import Plant
# - the status display: score and plant description # - the status display: score and plant description
# - the infow window. updated by visit/garden/instructions/look # - the infow window. updated by visit/garden/instructions/look
# thoughts on storage
# Right now, plants are stored in a few ways:
# - as a row in the garden db for displaying when users choose to view a garden. this can be thought of as a cache over the plant files in individual user's home .botany dirs. this is a sqlite3 file kept in the source directory for botany's code.
# - as a json file local to ~/.botany; this is, afaict, for people to use as a kind of API?
# - as a .dat file--a pickled representation of that plant--in ~/.botany. this is the actual savefile for a plant.
#
# the fundmental pieces of data for a plant are:
# - birth timestamp
# - last water timestamp
# - generation
# - mutation
#
# everything else is either flavor (art, adjectives, rarity) or can be derived
# (alive/dead, stage, growth rate, water level)
#
# the visitor system allows for other people to touch the last water timestamp
# which is an interesting permissions problem.
#
# it's tempting to re-imagine all of this as something centralized: a shared
# sqlite3 db tracks 100% of information on all plants and on visitation. This
# would simplify a lot about botany. I think there is something romantic about
# having a garden/plant file in one's home directory. This also reduces the
# likelihood of a centralized error wiping out plant data.
#
# So can a new botany be designed that
# - keeps plant files distributed
# - allows for visitation
# - can render an overview of a system's garden
# - can handle changes to a plant when botany isn't itself running
# - can handle changes to a plant from out-of-band (eg visitor) when botany is running
#
# that minimizes the chances for race conditions and reduces the redundancy of
# plant serialization?
#
# reduce down to a single game loop
# start by filling up .botany (json or sqlite3?) and consider garden generalization as an out of band task.
# create a world-writable sqlite3 db for visitors to write to
class DataManager(object): class DataManager(object):
# handles user data, puts a .botany dir in user's home dir (OSX/Linux) # handles user data, puts a .botany dir in user's home dir (OSX/Linux)
# handles shared data with sqlite db # handles shared data with sqlite db

View File

@ -311,6 +311,7 @@ class Plant:
self.write_lock = True self.write_lock = True
self.kill_plant() self.kill_plant()
while self.write_lock: while self.write_lock:
# TODO is this the culprit for the intermittent full-runaway botany?
# Wait for garden writer to unlock # Wait for garden writer to unlock
# garden db needs to update before allowing the user to reset # garden db needs to update before allowing the user to reset
pass pass