add project settings functionality to MapeoProject

[achou11]

Closes #167

Notes:

• implements project records indexing on the config store
• introduces the $setProjectSettings and $getProjectSettings methods (which also make it easier to test the indexing)

TODO:

• (better) tests
• update to @mapeo/schema https://github.com/digidem/mapeo-schema/issues/121
• update to @mapeo/schema https://github.com/digidem/mapeo-schema/issues/132
• (non-blocking) update to @mapeo/crypto Generate projectId with @mapeo/crypto? #171

[achou11]

running into a couple of implementation questions that I probably need some help with:

1. Because the project table lives in a separate database from the other mapeo schema data types, I need a Drizzle instance that uses a SQLite instance that points to the client db. The one created in MapeoProject only creates one pointing to the project db right now. At the time of writing, I currently add a "config" object that specifies the client db instance, which feels off. With this, every project that gets created will be sharing the same "client" db instance, which on paper makes sense but also has me somewhat skeptical...

2. What's responsible for actually creating the project i.e. writing the very first "project" record? Seems like that would be the responsibility of whatever holds the project DataType via dataType.create(...), which is the MapeoProject at the time of writing. However, since DataType.create is async, we can't call it in the constructor, meaning that we'd need to expose a public method that the creator of the instance would then call. For example, the pseudo-code for a wrapper client class createProject method would look something like:

class MapeoManager {
  async createProject(value) {
    const project = new MapeoProject(...)
    await project.$create(value)
    return project
  }
}

Does that seem reasonable, or do I need to approach the design of this a little differently? Or maybe I'm missing an important detail...

[achou11]

After discussion with Gregor:

1. My approach is valid. Not pretty but probably no noticeably better way of doing it for now

2. I was onto something here and turns out we need Add dataType.createWithDocId() method #190 in order to address the issue. That method will be used in the MapeoProject.$setProjectSettings to provide upsert behavior. So the wrapper client would create the MapeoProject instance and then calls $setProjectSettings, with the project setting "creation" being taken care of in the MapeoProject implementation

[achou11]

highlighting that this ideally would be using a more optimal variant of decode, which hasn't been implemented yet at time of writing

[achou11]

addressed via c6259d2

[achou11]

do i need to do any error catching/handling here?

[gmaclennan]

Yes, the decode() function will throw if it encounters a block that it does not know how to decode. These errors should just be ignored for now.

For errors in the indexWriter batch, I think it's ok to not catch them and let them bubble up to the dataStore

[achou11]

addressed via 6763de9

[achou11]

should this be string | string[]? Thought it would be, but then how would that get passed to dataType.getByVersionId? (which accepts string)

[gmaclennan]

I don't think we should have a second parameter here. Using this method should always just update the latest e.g.

async $setProjectSettings(settings) {
  const { project } = this.#dataTypes
  const existing = project.getByDocId(this.#projectId)
  if (existing) {
    return project.update([ existing.versionId, ...existing.forks ], {
      ...getValueOf(existing),
      ...settings
    })
  } else {
    return project[kCreateWithDocId](this.#projectId, {
      ...settings,
      schemaName: 'project'
    })
  }

[achou11]

addressed via 2cc9d44

[achou11]

I have this returning the entire project document for now, but guessing we'd want less information to surface in general.

[gmaclennan]

Yes I think return Omit<ProjectValue, 'schemaName'>

[achou11]

addressed via 82563b4

[achou11]

kind of forgot what defaultPresets represents - should it also be omitted here?

[gmaclennan]

I think this should be Partial<Omit<ProjectValue, 'schemaName'>>

default presets is configuration for which presets are shown to the user to select from.

[gmaclennan]

Actually I think we should modify the schema and consider all properties on projectSettings to be optional, and implement defaults in code.

[achou11]

Is it possible to modify the schema given https://github.com/digidem/mapeo-schema/issues/104?

[gmaclennan]

Yes, we allow fields to be undefined. We just don't allow them to be null

[achou11]

issue created: https://github.com/digidem/mapeo-schema/issues/132

[achou11]

I think this should be Partial<Omit<ProjectValue, 'schemaName'>>

addressed via 2cc9d44

[achou11]

I think there should be a comment here explaining what this is used for. took me a bit to figure out I needed to update it to add the project schema

[achou11]

just highlighting this as something that will eventually be updated