Joseph Ficara

My feedback

  1. 387 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    4 comments  ·  Azure Cosmos DB » Management  ·  Flag idea as inappropriate…  ·  Admin →

    The ability to rename databases and collections is not currently something that is in our road map.

    Currently the way to accomplish this task in Cosmos DB is to create a new collection with the changed name then use bulk exec or change feed to populate it.

    Thanks for your request and input on this. We may consider this for a future planning cycle.

    thanks.

    Joseph Ficara supported this idea  · 
  2. 219 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  Azure Cosmos DB » Other  ·  Flag idea as inappropriate…  ·  Admin →
    Joseph Ficara supported this idea  · 
  3. 3,822 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    80 comments  ·  Azure Cosmos DB » SQL API  ·  Flag idea as inappropriate…  ·  Admin →
    Joseph Ficara supported this idea  · 
  4. 493 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    6 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…

    Joseph Ficara supported this idea  · 
  5. 7 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Azure Search » Indexing  ·  Flag idea as inappropriate…  ·  Admin →
    Joseph Ficara commented  · 

    In addition the documentation and status codes returned regarding the existing functionally were not clear as of this writing, 2018-01-31. https://docs.microsoft.com/en-us/rest/api/searchservice/addupdate-or-delete-documents

    Paragraph 1:
    Status code 200 (OK) is returned for a successful response, meaning that all items have been stored durably and will start to be indexed. Indexing runs in the background and makes new documents available (that is, queryable and searchable) a few seconds after the indexing operation completed. The specific delay depends on the load on the service.

    Paragraph 2:
    Successful indexing is indicated by the status property being set to true for all items, as well as the statusCode property being set to either 201 (for newly uploaded documents) or 200 (for merged or deleted documents):

    Paragraph 1 indicates that a status code of 200 means that the data is durable and indexing will occur a few seconds after. Paragraph 2 seems to indicate a status of true and a status code of 200 Successful indexing has occurred. This is actually not the case, a status of true and 200 still mean the data is only durable, there is no status that indicates indexing was successful.

    Ideally it would be helpful to return a status code that indicates only that the data is durable, a 204 could be used in this case, which from the Azure Search documentation means "Success on PUT or POST. Index or documents uploaded successfully.", and a 200 meaning that its durable and indexing has been completed.

    Using a status of 200 to indicate its durable but indexing is still needed reduces the clarity of the interface as there is no provision for a status that indicates the data is durable and indexing has completed.

    Joseph Ficara supported this idea  · 
  6. 721 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    9 comments  ·  Azure Search » Indexing  ·  Flag idea as inappropriate…  ·  Admin →
    Joseph Ficara supported this idea  · 
    Joseph Ficara commented  · 

    In addition renaming of columns.

  7. 365 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  5 comments  ·  Azure Search » Client SDK  ·  Flag idea as inappropriate…  ·  Admin →
    Joseph Ficara commented  · 

    Any updates on the roadmap for this feature?

    Joseph Ficara supported this idea  · 
  8. 4 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  SQL Database  ·  Flag idea as inappropriate…  ·  Admin →
    Joseph Ficara shared this idea  · 

Feedback and Knowledge Base