Joseph Ficara

My feedback

  1. 7 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Web Apps  ·  Flag idea as inappropriate…  ·  Admin →
    Joseph Ficara supported this idea  · 
  2. 256 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    10 comments  ·  Azure Cosmos DB » Other  ·  Flag idea as inappropriate…  ·  Admin →
    Joseph Ficara commented  · 

    We are very much looking forward to this feature.

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

    Having the ability to backup and restore an index is very important for business continuity.
    Although its possible to reload an index, it will take days to reload our index given the amount of data in it.

    We rely heavily on Azure search and the recovery time objective supported by a re-index is well out of our range of acceptability from a business continuity perspective.

    Also having the ability to make a backup and restore it into a higher pricing tier would provide a quicker upgrade solution than populating an index from scratch for the sole purpose of upgrading to the next pricing tier.

    Additionally having this feature for internal integration tests is also very useful. In this use case it is helpful to have a golden copy of the index that we reset to after each integration test suite completes. Again being faster than rebuilding an index.

  4. 1,397 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    39 comments  ·  Azure Search » Pricing and Quotas  ·  Flag idea as inappropriate…  ·  Admin →
    Joseph Ficara supported this idea  · 
    Joseph Ficara commented  · 

    This is very important to us as well. As the business grows and becomes more successful the original tier may no longer scale to the current needs. Creating a new search service and loading it from scratch can be very time consuming given the amount of data that exists in current instance. Having a seamless way to upgrade to the next pricing tier would be very helpful in this regard.

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

    Its coming up on a year since this has been started, are there any updates you can share regarding progress and availability?

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

    We would also like support for IP firewall. V-NETs for azure search is also a workable solution. If an API Key gets compromised there is no defense in depth support with the current azure search service.

  7. 430 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    7 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  · 
  8. 4,205 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    93 comments  ·  Azure Cosmos DB » SQL API  ·  Flag idea as inappropriate…  ·  Admin →
    Joseph Ficara supported this idea  · 
  9. 493 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…

    Joseph Ficara supported this idea  · 
  10. 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  · 
  11. 745 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    10 comments  ·  Azure Search » Indexing  ·  Flag idea as inappropriate…  ·  Admin →
    Joseph Ficara supported this idea  · 
    Joseph Ficara commented  · 

    In addition renaming of columns.

  12. 377 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  · 
  13. 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