Create Task
Maniphest T8775

Resource Cache Database
Open, NormalPublic
Actions

Description

Data Model

"which version of krita created the cachedb, which version of the schema we're using"
version_information

id INTEGER PRIMARY KEY,
database_version TEXT
krita_version TEXT
creation_date TEXT

"Where the resource originally came from"

OriginType
    INTEGER originTypeId
    TEXT origin
        Installation
        Bundle
        AdobeLibrary
        User

"A place that stores resources"

Storage
    INTEGER storageId
    INTEGER originTypeId
    TEXT name
    TEXT location

""

Tag
    INTEGER tagid
    TEXT name
    TEXT tooltip
    INTEGER storageId

""

ResourceType
    INTEGER ResourceTypeId
    TEXT name
        PaintOpPreset
        BrushTip
        ...

""

Resource
    INTEGER resourceId
    INTEGER resourceTypeId
    TEXT name
    BLOB icon

"Metadata about a resource

ResourceData
    INTEGER resourceId
    TEXT key
    TEXT value

"The translation of a resource or tag"

Translation
    INTEGER translationId
    INTEGER originalId
    TEXT locale
    TEXT translation

"An instance of a resource as stored in storage"

ResourceVersion
    INTEGER versionId
    INTEGER resourceId
    INTEGER storageId
    INTEGER version
    TEXT location
    TEXT creationDate

"Links resources and tags"

ResourceTags
    INTEGER tagId
    INTEGER resourceId

Related Objects
Search...

rempt created this task.May 22 2018, 12:17 PM
rempt triaged this task as High priority.
rempt updated the task description. (Show Details)May 22 2018, 12:22 PM
rempt updated the task description. (Show Details)
rempt lowered the priority of this task from High to Normal.
dkazakov added a subscriber: dkazakov.May 22 2018, 9:46 PM

Hi, @rempt!

I have a couple of questions/proposals :)

  1. Do we store tag translations inside the database? If so, how will we generate these translations and upload them into the database from .po files? From some desktop files?
  1. Both Tag::tag and a Tag::tooltip are translatable?
  1. Why do we need Tag::storageId? Will it be null for all the user-defined tags?
  1. Should we store cache only for the last version of the resource, or for all of them?

We have two options, which one should we use?

  • We don't store any cache for non-last versions of the resources, only for the last one.
Resource
    INTEGER resourceId
    INTEGER resourceTypeId
    **TEXT uuid**
    **TEXT cachedName**
    **BLOB cachedIcon**
    **TEXT cachedMd5Sum**
    **INTEGER cachedFileSize**
    **DATE cachedFileModificationDate**

ResourceVersion
    INTEGER versionId
    INTEGER resourceId
    INTEGER storageId
    INTEGER version
    TEXT location
    TEXT creationDate
  • We do store cache for all the versions of resources.
Resource
    INTEGER resourceId
    INTEGER resourceTypeId
    **TEXT uuid**

ResourceVersion
    INTEGER versionId
    INTEGER resourceId
    INTEGER storageId
    INTEGER version
    TEXT location
    TEXT creationDate
    **TEXT cachedName**
    **BLOB cachedIcon**
    **TEXT cachedMd5Sum**
    **INTEGER cachedFileSize**
    **DATE cachedFileModificationDate**
rempt added a comment.May 23 2018, 7:34 AM
In T8775#143741, @dkazakov wrote:

Hi, @rempt!

I have a couple of questions/proposals :)

  1. Do we store tag translations inside the database? If so, how will we generate these translations and upload them into the database from .po files? From some desktop files?

We cache translations in the database. I haven't decided on the implementation yet -- it might be a good idea to put all tags in a desktop file, or to extract strings and have the tags in regular po files.

  1. Both Tag::tag and a Tag::tooltip are translatable?

No, the tag is the tag, and gets translated in the translation table. I'm not sure about the tooltip yet.

  1. Why do we need Tag::storageId? Will it be null for all the user-defined tags?

So we can figure out whether the tag came from Krita, a bundle or created by the user. It wouldn't be null if the user created it, it would refer to a storage entry that represents the folder on disk.

  1. Should we store cache only for the last version of the resource, or for all of them?

I intended it to be only the last version. The resource_version table (I found an SQL style guide after thinking up the schema, so the final names will be different) will store the location of the original file so we can go back. The resource itself will contain the cached data.

dkazakov added a comment.May 24 2018, 11:42 AM
In T8775#143756, @rempt wrote:
  1. Do we store tag translations inside the database? If so, how will we generate these translations and upload them into the database from .po files? From some desktop files?

We cache translations in the database.

Won't it be easier to just load all the strings (with context) into ki18n and use it for translations? Or you think it would occupy too much unnecessary resources?

I haven't decided on the implementation yet -- it might be a good idea to put all tags in a desktop file, or to extract strings and have the tags in regular po files.

What if we store each tag in a separate .desktop file? All the tags could be stored in a separate resources folder. Then people could use standard translation tools for translating them. Would it work?

Then we could search for these files on startup as for normal resources, and cache them into the database (with translations or not) as normal resources. The only question is where to store the linking of these "tag resources" to brushes ans stuff? Just storing the connections in a database is not portable... Perhaps, we could store the list of attached resources UUIDs in the .desktop file?

  1. Why do we need Tag::storageId? Will it be null for all the user-defined tags?

So we can figure out whether the tag came from Krita, a bundle or created by the user. It wouldn't be null if the user created it, it would refer to a storage entry that represents the folder on disk.

okay :)

  1. Should we store cache only for the last version of the resource, or for all of them?

I intended it to be only the last version. The resource_version table (I found an SQL style guide after thinking up the schema, so the final names will be different) will store the location of the original file so we can go back. The resource itself will contain the cached data.

So when opening history dialog, Krita will have to show the resource info directly from the file, right?

rempt added a comment.May 24 2018, 1:01 PM

Won't it be easier to just load all the strings (with context) into ki18n and use it for translations? Or you think it would occupy too much unnecessary resources?

I'm not 100% sure yet, it depends a bit on how good my SQL foo is going to be...

What if we store each tag in a separate .desktop file? All the tags could be stored in a separate resources folder. Then people could use standard translation tools for translating them. Would it work?

Yes, that's what I was thinking: one .desktop per resource

Then we could search for these files on startup as for normal resources, and cache them into the database (with translations or not) as normal resources. The only question is where to store the linking of these "tag resources" to brushes ans stuff? Just storing the connections in a database is not portable... Perhaps, we could store the list of attached resources UUIDs in the .desktop file?

The entire database is meant to be portable, though, from one system to another. It's one of the strengths of sqlite.

So when opening history dialog, Krita will have to show the resource info directly from the file, right?

When going back in history, we'd have to recreate that.

rempt updated the task description. (Show Details)May 31 2018, 8:14 AM
rempt updated the task description. (Show Details)Mar 4 2019, 11:13 AM