[DX] Add normalized project data into the database.

[klonos]

This is related to issues like #2548.

Add project data into the database. Make it normalized and easily accessible for database queries.

To follow up on #1: The system table already has the following columns:

• filename
• name
• type
• owner
• status
• bootstrap
• schema_version
• weight
• info

We'd like to propose adding two additional tables: projects and project_info, where data that applies to all project types can live in the projects table, and data that applies to only one type of project (or only one specific project!) can live in the project_info table.

projects could have the following columns:

• name (machine name of project - PRIMARY KEY)
• label
• description
• backdrop
• hidden
• required
• package
• tags
• stylesheets
• stylesheets-conditional
• scripts
• version
• dependencies
• bootstrap
• php

project_info can have the following columns:

• name (machine name of project - PRIMARY KEY)
• key
• value

---

Original issue:

It took a bit of pause and head scratching while reviewing the PR for #5820. There was a check for ($info_array['type'] == 'module' || $info_array['type'] == 'profile') and then a call to system_rebuild_module_data() in order to get the human-readable names of projects, and I thought "why not do the same for themes and layout templates as well?". Then I remembered all these inconsistencies we have all over the place, which urged me to file this issue here.

I would like to propose the following:

1. Have separate columns for the properties in the .info files of projects - not a single info column with a BLOB of serialized data as we currently have it (which forces developers to unserialize it each time). The serialized data in that BLOB contains duplicate information that can already be found in other columns of that table (namely project name and project type).
2. Add data from .info files of layout templates to this table as well.
3. [DX] Add a project_get_info helper function. #2385
4. [DX] Does system_get_info need to be updated to include 'layout' as $type? #2384
5. ...

[klonos]

PS: once this is done, we should revisit #5820 and the implementation in core/modules/system/views/views_handler_field_system_info.inc to ensure that we're able to pull info for all project types (should be a follow-up).

Various comments from that issue:

... Not all settings are provided, and some will only return a value for modules (not for themes). Empty strings are returned if the setting doesn't exist.

Layout template information is not stored in the system table, and therefore is unavailable to this handler. ...

One question, why one common field with a select list rather than individual fields? Not saying I prefer it the other way, but I find Views fields seem to lean toward granular options. Any particular reasoning here?

Thanks @docwilmot. The reason it's done this way is that Views field handlers are abstractions of select queries. Since the information handled by this handler comes from a single column (info in the table system), and since info contains a serialized array with ALL properties in the info file, you can't really do a select query for a single property. You get the whole info column at once, which has to be unserialized.

[jenlampton]

There are a few reasons info data isn't separated out into individual columns in the system table:

1. The system table is intended to track the current state of various things on the system. It's not a project data table. What's in the system table is only what the system needs to know to operate. If we make substantial changes to the system table there could be serious consequences (tagging with "needs benchmarks").

If we want to create a store of project data, I'd prefer that we add a new project data table, so that we aren't interfering with system operations. (also tagging with "needs more feedback") The views handlers should probably use this new table as the base table, and join to system only when enabled or schema_version data is necessary.

2. the info keys will be different for different types of projects, modules won't have layout info, themes won't have module info, etc.

I don't think it would make sense to make a database column for everything that might appear in the info file for any type of project, so as a rule of thumb, if it's not available for all project types, I think we should leave that information in info. Examples would include: base_theme, regions, default region,settings, engine, preview, dependencies, configure, etc). We can make exceptions for particularly valuable information as use-cases arise.

I'll add a list of properties that are consistent across all projects to the Original Post, and we can adjust as needed.

[yorkshire-pudding]

How about a project data table with common fields and a project info table with project_name, info_type, info_value fields that could be easily joined to the project table (assuming project data table has project_name also)?
I think file_metadata table works on a similar basis.

[jenlampton]

Brilliant! Why didn't I think of that? :)

@klonos I rewrote the issue and moved your original content to the bottom. I hope that's okay :)

[klonos]

Thanks @yorkshire-pudding and @jenlampton for chiming in. Yes, we seem to be heading to a good direction with this 👍🏼

[klonos]

...since both tables will be holding project info (or data from the .info files of projects), I would like these to be something more descriptive/self-explanatory, such as project_info (for the standard things that are common across all projects) and project_misc_info or project_extra_info (for things specific per project type, or any additional info that may come after we have #119).