Resolve entity framework warnings

[lsipii]

Resolves aspnet/entity framework generated warnings:

• comma separated list input values conversion configurations lacked a comparator: Certification.EscoUri, WorkPreferences.PreferredMunicipalityCode, WorkPreferences.PreferredRegionCode and WorkPreferences.WorkingLanguageEnum:
  • warning example: The property 'Certification.EscoUri' is a collection or enumeration type with a value converter but with no value comparer. Set a value comparer to ensure the collection/enumeration elements are compared correctly.
• the field PersonAdditionalInformation.Address marked as a required value: it's an ef-shared model that is "merged/combined " with the parent one and when the field was defined as optional the entity framework flagged it as odd behaviour
  • warning example: The entity type 'Address' is an optional dependent using table sharing without any required non shared property that could be used to identify whether the entity exists. If all nullable properties contain a null value in database then an object instance won't be created in the query. Add a required property to create instances with null values for other properties or mark the incoming navigation as required to always create an instance.
• database queries that included relations (a JOIN-clause) needed a specification which query strategy to use: https://learn.microsoft.com/en-us/ef/core/querying/single-split-queries
  • warning example: Compiling a query which loads related collections for more than one collection navigation, either via 'Include' or through projection, but no 'QuerySplittingBehavior' has been configured. By default, Entity Framework will use 'QuerySplittingBehavior.SingleQuery', which can potentially result in slow query performance. See https://go.microsoft.com/fwlink/?linkid=2134277 for more information. To identify the query that's triggering this warning call 'ConfigureWarnings(w => w.Throw(RelationalEventId.MultipleCollectionIncludeWarning))'
  • note: in this case the QuerySplittingBehavior.SingleQuery is what we want as the data relation structure is all related and wanted to be attached to single entities (of a Person-model) so there's no performance penalty as described by the frameworks warning
• configured the aspnet core data protection mechanism to use key persistence using the database as in lambda/container-scheme the filesystem based persistence would not work: https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/overview?view=aspnetcore-6.0
  • warning examples:
    • Storing keys in a directory '/root/.aspnet/DataProtection-Keys' that may not be persisted outside of the container. Protected data will be unavailable when container is destroyed.
    • No XML encryptor configured. Key {52c377ea-769a-4d0c-a84f-eca479935816} may be persisted to storage in unencrypted form.

[lsipii]

Tähän on muuten hankala testausohjetta kirjoitella, kuin että logeista pitäisi hävitä ym. waroitukset myös lokaalissa ja appiksen käytön pitäisi toimia normaalisti.

[LauriGofore]

.AsSingleQuery()

Erikoista että tuota pitää spämmätä kaikkialla, jos se on kuitenkin default mitä käytellään. Toisaalta, ei sitten osanne antaa varoitusta asiasta..

Voisko tuosta asetella jotenniin globaalin asetuksen, minkä sit vois case-kohtaisesti ylikirjoitella tarvittaessa, https://learn.microsoft.com/en-us/ef/core/querying/single-split-queries#enabling-split-queries-globally

e: no ei noita tietysti niin paljon ole, että vaatis mitään enempää globaalia säätöä..

[LauriGofore]

🤫 🤐

[LauriGofore]

In cases where the built-in comparison behavior isn't appropriate, users may provide a value comparer, which contains logic for snapshotting, comparing and calculating a hash code.

Jos built-in toimii (ilmeisesti toiminut kuitenkin tähän asti), niin eikö tuota voi hiljentää mitenkään vaikka case-kohtaisesti, vs. määritellä tuollanen hc valueComparer? Tietysti, onhan se eksplisiitimpi etenkin jos olisi useampaa tyyppiä miten pitäis ajella ja tarkistella.

[lsipii]

Jos built-in toimii (ilmeisesti toiminut kuitenkin tähän asti), niin eikö tuota voi hiljentää mitenkään vaikka case-kohtaisesti, vs. määritellä tuollanen hc valueComparer? Tietysti, onhan se eksplisiitimpi etenkin jos olisi useampaa tyyppiä miten pitäis ajella ja tarkistella.

EF Coren varoitus-viestejä voisi kyllä globaalilla tasolla filtteriödä, mutta en jotenkin nyt hoksaa miten se hiljennys kävisi case-kohtaisesti kuin että tarpeeksi tarkka globaali sääntö. Noi kyseiset mallit on kyllä samaa tyyppiä että käy ihan järkeen että niillä on oma käsittelijänsä.