Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi-Part Composite Key causes "Find" Exception using tryFindEntity / updateEntity #131

Closed
kirse opened this issue Dec 14, 2021 · 4 comments · Fixed by #132
Closed

Multi-Part Composite Key causes "Find" Exception using tryFindEntity / updateEntity #131

kirse opened this issue Dec 14, 2021 · 4 comments · Fixed by #132

Comments

@kirse
Copy link

kirse commented Dec 14, 2021

General setup:

// Whatever context config, but create an entity with composite key:
modelBuilder.Entity<CompositeKeyEntity>().HasKey([| "Key1"; "Key2"; "KeyN" |]) |> ignore

Then try:

tryFindEntity<CompositeKeyEntity> db (fun (x : CompositeKeyEntity) -> (x.Key1, x.Key2, x.KeyN) :> obj)

Or this:

tryFindEntity<CompositeKeyEntity> db (fun (x : CompositeKeyEntity) -> 
    let key : obj[] = [| x.Key1; x.Key2; x.KeyN |]
    key)

Which causes this:

System.ArgumentException: Entity type 'CompositeKeyEntity' is defined with a 3-part composite key, but 1 values were passed to the 'Find' method.
at Microsoft.EntityFrameworkCore.Internal.EntityFinder`1.FindTracked(Object[] keyValues, IReadOnlyList`1& keyProperties)
at Microsoft.EntityFrameworkCore.Internal.EntityFinder`1.Find(Object[] keyValues)
at Microsoft.EntityFrameworkCore.Internal.InternalDbSet`1.Find(Object[] keyValues)

Not hugely impactful since .Find() can be used directly, but treating key as obj instead of obj[] means composite keys can't be used with the helper functions (and they are helpful in many cases).

simon-reynolds added a commit that referenced this issue Jan 16, 2022
## [6.0.6] - 2022-01-16

### Fixed
- Prevent ManyServiceProvidersCreatedWarning exception - #130
- Helper methods should allow composite keys - #131
- AlterColumn operations no longer create unnecessary migrations - #133
@simon-reynolds
Copy link
Collaborator

This has been fixed in v6.0.6

The only caveat is that a composite key has to be an obj[] or obj list, so you'd need to use the second option above

tryFindEntity<CompositeKeyEntity> db (fun (x : CompositeKeyEntity) -> 
    let key : obj[] = [| x.Key1; x.Key2; x.KeyN |]
    key)

@kirse
Copy link
Author

kirse commented Feb 1, 2022

Awesome, thanks, love the project and using it daily!

@simon-reynolds
Copy link
Collaborator

Thank you, it's always great to hear when someone is getting some use out of it

@kirse
Copy link
Author

kirse commented May 11, 2022

On rev-ing to 6.0.6 it appears the DbContextHelpers.fs methods now return everything of type obj instead of 'a, is this intended?

Ex:

let myBlog = tryFindEntity<Blog> db id
// type of myBlog is now obj instead of Blog

I think this breaks a lot of the docs here as well: https://efcore.github.io/EFCore.FSharp//How_Tos/Use_DbContextHelpers.html

@simon-reynolds Any insight, should I create a separate issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

2 participants