DocumentDB coder

My feedback

  1. 274 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    6 comments  ·  Azure Cosmos DB » Management  ·  Flag idea as inappropriate…  ·  Admin →
    DocumentDB coder supported this idea  · 
  2. 502 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    7 comments  ·  Azure Cosmos DB » SQL API  ·  Flag idea as inappropriate…  ·  Admin →

    Thank you for your feedback. I have discussed this in more detail with our team.

    You are correct the workaround suggested to use .AsEnumerable().FirstOrDefault(). should not be a recommended work around. This way results in materializing all documents on the client first before getting the 1st document, which is not very efficient and the exact opposite of what you are trying to achieve.

    Instead we recommend you use Take(1).AsEnumerable() and then .First() or .Single() or .FirstOrDefault() for Single() and First(). Take(1) is translated to SELECT TOP 1 and is processed server-side so more efficient than the previous suggestion and is what you are trying to achieve.

    As to the original ask. The support for these operations can be done, but this work is not prioritized against the other work we want to deliver. I will move this back as unplanned but please note this is on our roadmap.

    Thanks again…

    DocumentDB coder supported this idea  · 
  3. 1,294 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    21 comments  ·  Azure Cosmos DB » SDK  ·  Flag idea as inappropriate…  ·  Admin →

    We recently released support for client-side transactions in our .NET SDK.

    https://devblogs.microsoft.com/cosmosdb/introducing-transactionalbatch-in-the-net-sdk/

    We would like to get your feedback on this to understand if this meets your needs for transaction support. Please read our announcement and/or feel free to try our new support then please respond to this one question survey.

    https://forms.office.com/Pages/ResponsePage.aspx?id=v4j5cvGGr0GRqy180BHbR_Lrg0nxRBtErN-GyphxUs9UQ0c1STlJTDVOT1JXUzhYVkYzU1JZSU5BTi4u

    Thank you.

    An error occurred while saving the comment
    DocumentDB coder commented  · 

    Absolutely agree.

    Unit of Work pattern is vital -
    Start some unit of work (or "Transaction") do a bunch of stuff, then commit everything to the server at once in a atomic transaction.

    I don't like server side programming for a number of reasons
    1) it's a different language so not great for skill reuse when all our devs know & use C#
    2) they're impossible to debug
    3) they're a pain to deploy to multiple collections
    4) they're a pain to keep in sync between prod & dev
    5) they're impossible to unit test

    and finally, and probably most importantly
    6) they force me to move application logic out of my application and on to the server which is just bad.

    Note, this doesn't have to "lock" resources like a Begin Transaction / Commit Transaction on SQL Server would do, it should just execute all the changes in an implict transaction just like executing a stored proc currently does.

    I want the same functionality without the pain of server-side programming

    DocumentDB coder supported this idea  · 

Feedback and Knowledge Base