Index tags #100
Index tags #100
Conversation
✅ Deploy Preview for toodles ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
At present, we're only doing this on todo creation. It must be done for update too. We also aren't indexing tags because arrays of objects can't be indexed - neither can their individual keys (at least not with Dexie's indexes syntax). Consider indexing the keys separately in a new pseudo-attribute: Really what I would say that probably means tags indexing should be handled at the point of introducing interactivity, so on #97. I'll link to here from there... |
|
Bit of a problem at the moment even updating this so that tags are updated when the description is. I can set the values and check them in-memory within the model... but they're not updating in the persistence layer. Will have to have more of a look at this, maybe tomorrow. |
|
Actually, this is why: db.todos.update(id, { description: todo.description, priority: todo.priority }).then().catch()That's the saving to the database in the update function in the We should prefer, I think, not to manually specify each attribute but instead pass along all attributes that are potentially changed. But I worry that there was a reason it was setup this way - thinking back, I remember having some trouble that led to this decision in the first place. |
|
Issue appears to be that Attempted to replace Consider then that these arrays should be generated in the same way as tokens, at the Database Plugin level? Does that feel like the right place for them? They are intended for indexing, after all. It is essentially their sole purpose... Yeah, that's fine. It just feels like this really shouldn't be a problem... |
|
Yup, that works. My one concern about that is... what about interactive tags? These are by nature intended to be individually updatable. Is that possible now that tags are being parsed at the plugin level? Something to keep in mind. |
|
Failing tests pertain to simple presence check of projects, contexts and tags on todos at the model layer which now has no notion of them until the Todo has been saved. (I mean it has a notion that their keys exist, just not that the Todo has any associated tags since these will be parsed once saved.) Something to look at tomorrow. |
|
Skipping those tests. They're redundant in that the model now no longer does the separation, the database does on save and update. I would prefer if the Todo model maintained control of this, but Dexie complains a lot if I try to update array values. We could work around this by saving objects like We could instead do something like... { 'firstTag': { value: 'firstValue' }, 'firstTag': { value: 'secondValue' } }Array-like object approach obviously works here, but it won't be indexable... In fact, I don't believe either approach is indexable as this second approach depends on dynamic keys. |
|
I believe this is the error I was getting: https://dexie.org/docs/DexieErrors/Dexie.DataCloneError Arrays should be supported... |
|
Issue is this... Class returns Proxy Array instead of array object itself... Not sure why. Obviously it's a pain in the ass. We can work around this at the point of the In fact, this means I can do this: db.todos.update(id, JSON.parse(JSON.stringify(todo))).then().catch()I no longer need to specify individual keys, as I was previously complaining about. That's an improvement. |
|
Let's also index tagKeys. We'll do this at the database level since it is purely an indexing concern. We could also index tagValues: `
...,
*tagKeys,
*tagValues
`Doing so would enable us to sort tagValues alphabetically quickly using the index. Useful. As already discussed, tags may have hidden values that are intended to be more comparable/sortable than their presented values. For instance Alternative to hidden values, we could enforce a formatting rule: |
|
How sortable are tagValues (being contained in an array) anyway... We wouldn't be able to tell which value belongs to which key. We'd want to sort individual values from the tagValues array against other individual values from arrays on different records. And we'd need these to be identifiable by key, despite being stored here without them... What this really calls for is a Tag model, stored separately, having Technically the keys within the index are universally sortable (despite being stored in arrays on individual records)... but we still have the problem of telling one value belonging to a certain key apart from another belonging to a different key. Even if we filter todos by tagKey, there may still be false positives pulled into the sorting of tagValue. Compound index ...there's also no indication that multi-value indexes are permitted within compound keys. I'm convinced: This is better handled by a separate Tag class, given which... it becomes redundant to index these on Todo at all. Advise: We skip tagKeys and tagValues indexes at this time, and consider introducing a Tag class to handle these in the future. |
|
All of that said... This is done! It may be entirely changed in the future - if a separate class for Tag works, it may be repurposed or lay the groundwork for Project, Context, Hashtag and perhaps Priority classes in the future. Though we should do this only if there is a reason they are necessary - as is, they should be perfectly searchable/sortable as is. Tags are unique in being comprised of more than one part. |
closes #98
Internal use. Do not delete.