Update components and institutions in metabase

[christoph-maurer]

I think that the UUIDs of components have change between IGSDB V1 and V2. Maybe also the UUIDs of institutions and the names of components and institutions.

@simon-wacker Which options do we have to update the components and institutions in the metabase? Which option do you recommend?

[christoph-maurer]

@danielmcquillen writes:

Yes we store uuids for each manufacturer. A manufacturer is a type of "entity" in our database. Another entity type is "non-profit".
The graphQL API will return entities if you query for entity or if you query for institution...we added institution as a convenience term to support BED. I've updated the help docs to clarify:

Meanwhile, yes we don't yet guarantee uuids across versions, or even builds. We're still in active development so uuid is more for API completeness and testing. At a later date ( to be determined by Robin and Jacob ) we will lock these uuids in.

[simon-wacker]

The UUIDs generated by the metabase are not meant to change but to stay the same for the whole lifespan of the metabase. If you are certain that you really want to change them in the metabase, I can probably somehow associate old UUIDs with new UUIDs and generate SQL queries that make the necessary changes.

[danielmcquillen]

Hi @christoph-maurer and @simon-wacker. I had a chat with @RDmitchell in our meeting yesterday about this issue.

We would be amenable to coming up with a workflow to match uuids in IGSDBv2 to the original uuids from the 'icon' version of the IGDB and which you've stored in BED...it's just that we won't be able to do this until we've gotten Checkertool and the IGSDBv2 operational with the feature set Robin and Jacob are looking for.

So I don't think you'll need to change any uuids you have stored in BED, we'll just have to come up with a way to reliably match and reset those uuids on our side to match (probably by using NFRC ID ...and if necessary other traditional 'identifiers' like file name...).

[christoph-maurer]

Sounds good, @danielmcquillen , thank you! When do you roughly estimate that the uuids could be matched? We would then inform the software companies accordingly.

[danielmcquillen]

@christoph-maurer I spoke to @RDmitchell and we agreed end of May or mid-June would be a reasonable target to have the uuids in v2 matching those published in v1. I hope this isn't inconvenient for you and the team.

[christoph-maurer]

Thank you for the estimation, @danielmcquillen and @RDmitchell !

[danielmcquillen]

@christoph-maurer @RDmitchell I've done a preliminary sync of IGSDBv2 with the uuids stored in the ICON version of IGSDB.

Note that the ICON version of the IGSDB has not been updated in some time, so there are new products that do not appear in it, and there are products that have since been removed.

At this point in development:

1. We cannot guarantee every product that appears in the ICON version of IGSDB has the same uuid if that product appears in the IGSDBv2
2. We cannot guarantee products in the IGSDBv2 that do not appear in the ICON version of the IGSDB will have permanent and consistent uuids.

...but we did try to get the uuids to be more in sync, so that if a uuid appears for a product in the ICON version of the IGSDB, the product has the same uuid in the IGSDBv2.

This is unfortunately the best I can do at the current time.

Once the IGSDBv2 and Checkertool are working together cleanly and all critical feature requests have been implemented and tested, the only way products will be added to the IGSDBv2 is via Checkertool.

To prepare for that time, we should look at coming up with a way for Checkertool to request uuids from BED when necessary, and in which situations it will want to do that:

• New product creation
• New version for an existing product? (and what set of changes prompts a new version?)
• New Entity (manufacturer) creation

[christoph-maurer]

Thank you for the update @danielmcquillen !

• New version for an existing product? (and what set of changes prompts a new version?)

I propose to register the new version in the metabase www.buildingenvelopedata.org/graphql as a new product and to connect the old version of the product and the new version with the relation variantOf. The field availability can be used to share when the two versions were commercially available.

Another option is to keep the existing product in the metabase and replace the optical data set of the old version by the optical data set of the new version.

• New product creation
• New Entity (manufacturer) creation

You can use the mutations createComponent and createInstitution to create new products and manufacturers.

@simon-wacker Can they already use createComponent and createInstitution or do they need to wait until the access right management is fully developed?

[simon-wacker]

The access right management needs to be fully developed and deployed first. If that takes too long, I can come up with a temporary custom solution.

[christoph-maurer]

@simon-wacker The access right management takes too long. Please develop a temporary custom solution. Thank you!