Cosmos: Add basic support for collections and dictionaries of primitive types

[AndriySvyryd]

It should be possible to implement this without a ValueConverter because Cosmos supports them natively.

This issue doesn't include server translation of queries with any methods using properties of these types, essentially they will be treated as atomic units.

[kierenj]

Hi, I'm keen to understand the propose-punt label please? I understand Backlog means this is vaguely planned for the future. Am keen to see if a project in 3-6 months should go the EF Core / Cosmos route or not - understand you can't give a definitive on this feature but just so I can guess the odds :) Thanks

[smitpatel]

@kierenj - We use propose-punt label for issues which we had planned for certain release but due to time constraints we ended up removing it from that release. Like this issue was planned for 3.0 but we had more work in 3.0 then what can be done in the time we got. So propose-punt label signifies that we consider this should be punted from 3.0 release. We go through such issues and decide if we can punt past 3.0 or we need to do it in 3.0. This issue got cut and propose-punt became punted-for-3.0.

This issue is currently in backlog milestone so we are not working on it for our next release 3.1. Cosmos being a new provider which is going to be RTM first time in 3.0, we are going to evolve cosmos based on user feedback. We will prioritize adding features which are requested by many customers. When planning a release, we look at how many people have voted for a feature to decide if it is in demand. Please upvote first issue if you need this.

[svrooij]

It seems weird to me that the provided documentation states how easy it is to embed entities, that I couldn't believe that embedding a simple string collection is unsupported.

@ajcvickers or @smitpatel do you guys maybe have an update for us? Since EF Core 5 is just released and this still isn't supported.

[kierenj]

@svrooij Strings aren't entities, of course. I think the documentation is accurate

[svrooij]

@svrooij Strings aren't entities, of course. I think the documentation is accurate

Yes, if you put it that way, sure. But I wasn't talking about the documentation, I was talking about that it's weird you're able to embed entire objects but not a collection of strings. Even more because cosmos supports the ARRAY_CONTAINS query function.

So if I stop using the EF core framework and just connect to plain cosmos I can set a property to a string collection and even use ARRAY_CONTAINS to query based on the values.

[Assassinbeast]

It should be possible to implement this without a ValueConverter because Cosmos supports them natively.

@AndriySvyryd can you show an example on how to do it with a ValueConverter? I would really appreciate it.

[Marusyk]

@Assassinbeast
something like

modelBuilder.Entity<YourEntity>()
        .Property(e => e.Strings)
        .HasConversion(
            v => string.Join(',', v),
            v => v.Split(',', StringSplitOptions.RemoveEmptyEntries));

[Assassinbeast]

modelBuilder.Entity<YourEntity>()
        .Property(e => e.Strings)
        .HasConversion(
            v => string.Join(',', v),
            v => v.Split(',', StringSplitOptions.RemoveEmptyEntries));

@Marusyk Thanks! So this will mean in my C# code, that its a string array, but in CosmosDB, it will become a single string. That means I cant make a CosmosDB query against an array. Is that correct?

[svrooij]

That means I cant make a CosmosDB query against an array. Is that correct?

That is exactly the problem. This way it is saved but you cannot query for it.

[Drew-E]

Is there any update on this? It definitely missed 5.0 as well.

[AndriySvyryd]

@Drew-E It's in the Backlog milestone, meaning it's not planned for 6.0 either

[pcbl]

Hi Folks,

Facing same issue. Just need to save an double[], but using the folowing code:

location.Property(l => l.Coordinates).HasConversion(t => JsonConvert.SerializeObject(t),
                                             s => JsonConvert.DeserializeObject<double[]>(s)).ToJsonProperty("coordinates");

It gets saved as:

"coordinates": "[-44.431451,-16.223516]"

But I expect:

"coordinates": [-44.431451,-16.223516]

This EF Core Cosmos useless on my case as I need to run Spatial Queries against the data. Quite annoying to see that this issue is open for so long, but still not in place.

That way I am forced to use CosmosDB SDK directly, which I wanted to avoid on this specific scenario...

Are there any workaround I could make to overcome this issue until there`s a fix for it? Tried many options, but none worked... (Actually, there is, check next "Edit/Update")..

Edit/Update
A Possible workaround is to use the "__jObject" shadow property over the EF Entry... more info on:
https://docs.microsoft.com/en-us/ef/core/providers/cosmos/unstructured-data

By doing that you are actually manipulating the real json which will be persisted on cosmos. As the MSDN mentions, that should be a last resort... So far that is the only way I managed to save the array as expected... on my case as a double[]...

[AndriySvyryd]

@pcbl Spatial support is tracked by #17317

[pcbl]

Thanks for the Heads up, @AndriySvyryd !
As far as I could see, this feature is on the backlog and might come sometime in the future. Or do you have any information about when it could be available?

[AndriySvyryd]

For issues in the backlog we don't have any specific plans, they are reprioritized after each release.

[PaulOst]

Is first-class support for collections and dictionaries of primitive types anywhere in our future? Why is such a basic capability in the backlog for so long? Not having this capability is a showstopper for my team. Whatever your reprioritization plans are you are giving us the impression that the EF Core provider just isn't important.

[ghost]

This is a huge issue for us too. Get Outlook for Android<https://aka.ms/ghei36>

…

________________________________ From: paulost <notifications@github.com> Sent: Sunday, March 7, 2021 10:38:11 PM To: dotnet/efcore <efcore@noreply.github.com> Cc: Eric Blankenburg <eric.blankenburg@hotmail.com>; Manual <manual@noreply.github.com> Subject: Re: [dotnet/efcore] Cosmos: Add basic support for collections and dictionaries of primitive types (#14762) Is first-class support for collections and dictionaries of primitive types anywhere in our future? Why is such a basic capability in the backlog for so long? Not having this capability is a showstopper for my team. Whatever your reprioritization plans are you are giving us the impression that the EF Core provider just isn't important. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fefcore%2Fissues%2F14762%23issuecomment-792439528&data=04%7C01%7C%7Cdea9d4e9750d423a8e4f08d8e1e39963%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637507714933524718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ECypi1cBM7rLDnCFWy7U%2Bm1cUIuOEYId%2BhvRIvvUX1U%3D&reserved=0>, or unsubscribe<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAC2LRVVHPCGRR5AY3LWX2ITTCRBCHANCNFSM4GYZWGIA&data=04%7C01%7C%7Cdea9d4e9750d423a8e4f08d8e1e39963%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637507714933524718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wtPYo0nO5drvNEIC2GVJn3byPyQqsoaTFnXrwDs6C4w%3D&reserved=0>.

[pcbl]

@ericb-blankenburg , @PaulOst ,
On my Team we end up not using EF Core for the objects we store on Cosmos and relies on stuff like GeoSpatial data and so on. For Collections and Dictionaries we did not notice the issue as on the case in question it was a simple object with coordinates. At the end of the day we implemented a repository using CosmosDB SDK directly... For now our CosmoDB repository is somehow very limited as we hope to switch it to the EF Core version later down the road... But when that will be? Not so sure.. :-)

[Drew-E]

Yes, there are workarounds. We could modify our document structure to use a list of objects with a single property. We can use the Cosmos SDK instead of EF Core. But really, this is such a basic feature that it should be supported by EF Core.

Why such a low priority on supporting this? Are there not enough people that require it? Is the effort too large? Is every backlog item ahead of this one really a higher priority? A little transparency would be great.

[AndriySvyryd]

You can read about our planning process, based on it we came up with the following plan. It does have Cosmos database provider in it, but the details haven't been decided as it depends on the progress of other features in the plan. As soon as the team members that can work on Cosmos finish their assigned committed features we will update the plan.

You can see exactly what we are currently working on in the biweekly updates.