Imports And The New Model
Well, I dragged Photo Bucket out today to work on it a bit.
It's fallen by the wayside a little, and I've been wondering if it's
worth continuing work on it. So many things about it that need to be
looked at: the public site looks ugly, as does the admin section;
working with more than a single image is a pain; backup and restore
needs to be added; etc.
I guess every project goes through
this "trough of discontent" where the initial excitement has warn off
and all you see is a huge laundry list of things to do. Not to mention
the wandering eye looking at
the alternatives.
But I do have to stop myself from
completely junking it, since it's actually being used to host the Folio Red Gallery. I guess my
push to deploy it has entrapped me (well, that was the idea of pushing
it out there in the first place).
Anyway, it's been a while
(last update is
here) and the move to the new model is progressing. And it's
occurred to me that I haven't actually talked about the new model (well,
maybe I have but I forgot about it).
Previously, the root
model of this data structure is the Store
. All images belong to a
Store
, which is responsible for managing the physical storage and
retrieval of them. These stores can have sub-stores, which are usually
used to hold the images optimised for a specific use (serving on the
web, showing as a thumbnails, etc). Separate to this was the public site
Design
which handed properties of the public site: how it should look,
what the title, and description is, etc.
There were some serious issues with this approach: images were
owned by stores, and two images can belong to two different stores, but
they all belonged to the same site. This made uploading confusing: which
store should the image live on? I worked around this by adding the
notion of a "primary store" but this was just ignoring the problem and
defeated the whole multiple-store approach.
This is made even
worse when one considers which store to use for serving the images. Down
the line I was hoping to support virtual domain hosting, where one could
setup different image sites on different domains that all pointed to the
same instance. So imagine how that would work: one wanted to view images
from alpha.example.com
and another wanted to view images from
beta.example.com
. Should the domains live on the store? What about the
site designs? Where should they live?
The result was that
this model could only really ever support one site per Photo Bucket
instance, requiring multiple deployments for different sites if one
wanted to use a single host for separate photo sites.
So I re-engineered the model to simplify this dramatically. Now, the
route object is the Site
:
Here, the Site owns everything. The images are associated with sites,
not stores. Stores still exist, but their role is now more in-line with
what the sub-stores did. When an image is uploaded, it is stored in
every Store of the site, and each Store will be responsible for
optimising it for a specific use-case. The logic used to determine which
Store to use to fetch the image is still in place but now it can be
assumed that any Store associated with a site will have the image.
Now the question of which Store an image should be added to is
easy: all the them.
Non-image data, such as Galleries and
Designs now live off the Site as well, and if virtual hosting is added,
so would the domain that serves that Site.
At least one site
needs to be present at all time, and it's likely most instances will
simply have a single Site for now. But this assumption solves the upload
and hosting resolution issues listed above. And if multiple site support
is needed, a simple site picker can be added to the admin page (the
public pages can will rely on the request hostname).
This has
been added a while ago, and as of today, has been merged to main
. But
I didn't want to deal with writing the data migration logic for this, so
my plan is to simply junk the existing instance and replace it with the
brand new one. But in order to do so, I needed to export the photos from
the old instance, and import them into the new one.
The
export logic has been deployed and I've made an export it this morning.
Today, the import logic was finished and merged. Nothing fancy: like
the export
it's only invokable from the command line. But it'll do the
job for now.
Next steps is to actually deploy this, which I
guess will be the ultimate test. Then, I'm hoping to add support for
galleries in the public page so I can separate images on the Folio Red
Gallery into projects. There's still no way to add images in bulk to a
gallery. Maybe this will give me an incentive to do that next.