'StoreId' - The biggest imag design flaw by now

When we designed the imag core functionality - the imag “Store” - we introduced a type called StoreId.

It turned out that the way we designed this type was a big mistake and turned out to be the first big imag design flaw by now. With this post I try to wrap my head around possible solutions to this flaw.

What is this about?

So we wrote the StoreId type. It is a wrapper around std::path::PathBuf, so it is basically a path. We wanted it to be the path to a store entry, but it should be absolute to the store root itself. So a valid StoreId object could be "note/car" - it would uniquely identify a file in the store. We made the StoreId also contain a version part, to be able to write imag modules which could check their data for compatibility with the current version of the library.

The Problem is that we just wrapped the path type. A StoreId can be created from any PathBuf and even from any String - which clearly is not the way it is supposed to be.

We didn’t use the type system enough. We should have designed this type more carefully. Lessons learned, I would say.

I know that I should write I messed up, but as the StoreId type was also designed by my friend Marcel, I use the term we.

How to clean this up?

Well, this is the hard part. As we do not have a release yet, we do not have to be backwards compatible, so there is no problem with that.

Anyways, we need to rewrite a lot of code to fix this design flaw. As imag gets more momentum in the rust community, this gets more important. This design flaw is actually blocking some other things, as we cannot rely on the properties of the StoreId as we should be able to.

One idea is to rip out the StoreId type completely and redefine it. In my opinion, a StoreId should only be constructed by the Store, upon request by the store user. That means that the user should be able to store.new_id("module", "path/to/entry") which then creates a new StoreId that points to $STORE/module/path/to/entry. That would be a clean way. The StoreId type then may contain functionality to create, retrieve and get and maybe even delete the entry it points to (so it contains a reference to the actual Store object internally).

I’m still not sure about the details. As said, I try to wrap my head around this problem with this very article.