We are using Firestore in the product we are developing, and we occasionally get errors caused by trying to add undefined values to a document.
As a general rule, I believe that external technologies should be operated according to the designer’s philosophy, and I thought that options such as ignoreUndefinedProperties should be applied with default settings unless there is a reason to do otherwise.
However, I am considering setting ignoreUndefinedProperties to true because we sometimes accidentally try to update data with value undefined.
Why does ignoreUndefinedProperties have a default value of false?
And, What do you think are the dangers or disadvantages of setting this to true?
Related
Very simple:
Let’s say we use RTK-Query to retrieve the current weather.
For that, I pass to the endpoint the arg ‘Paris’ as city.
It will serve the current weather of my « game ».
Then later, in a Redux selector, I need to compute some derived state based on that current weather.
How to read the state without having to pass the cache key « Paris »?
Indeed, that knowledge of « Paris » was only necessary at the beginning of the app.
It seems that with RTK-Query we’re stuck since you have to pass the argument that was used (the cache key) to the endpoint#select method.
Am I right in saying that RTK-Query does not currently allow that kind of state reading:
« select that current (and single) store entry X whatever the argument that was needed at loading time is ».
No, since that's an edge case.
Usually, there are multiple cache entries per endpoint, and there is also no concept of a "latest entry" or something, since multiple different components can render at the same time, displaying different entries for the same endpoint - the concept of a "latest" there would come down to pretty random React rendering order.
The most common solution would be to just safe "Paris" somewhere in global state to have it readily available, or to write your selector against RTKQ store internals by hand (although there might be changes to the state internals in the future).
The azure cosmos db documentation mentions following in the index transformation section :
When you move to None indexing mode, the index is dropped immediately. Moving to None is useful when you want to cancel an in-progress transformation and start fresh with a different indexing policy.
I have a partitioned collection with custom indexing policy with indexing mode consistent. Since there is no transformation progress available for a partitioned collection, so before starting any new indexing policy update, I was thinking of using None mode to cancel any in progress transformation and start the new one(consistent mode). But will this cause the entire index to get recreated, even if, just a new path was added?
If answer is yes, what is the best way of checking if no transformation is in progress before starting a new one?
Welcome to StackOverflow, Jatin! I am from the CosmosDB engineering team.
We do have transformation progress now for a partitioned collections - this was released recently. This can be fetched by setting the header 'x-ms-documentdb-populatequotainfo' to True. This header, in addition to providing quota and usage information for a partitioned collection, is also used to piggyback the index transformation progress information for partitioned collections.
However, you do not need to wait for the progress to complete before changing your indexing policy. Even though this would mean that it could take longer for our background re-indexing to finish all previous index updates and catch up to your latest indexing policy, there is an opportunity for the transformations to be online, meaning that queries could continue to work based on the changes between the indexing policy updates. For example, if the only change was adding paths throughout the transformations, queries on paths that are already indexed will continue to work throughout the reindexing process, assuming that the indexing mode was consistent through all the updates.
However, if you want your new index to be effective potentially sooner, then your suggestion of transitioning to None and then to Consistent could work. Please note that this is equivalent to an offline index rebuild, meaning the existing index will be deleted and the new one will be constructed from scratch. Queries will not return consistent results on any path up until the reindexing process completes.
Welcome to Stack Overflow!
Simply change the indexing policy from Custom to Consistent. Skip going to None and go directly to Consistent indexing policy:
All index transformations are performed online. The items indexed per the old policy are efficiently transformed per the new policy without affecting the write availability or the throughput provisioned to the container. The consistency of read and write operations that are performed by using the REST API, SDKs, or from stored procedures and triggers is not affected during index transformation.
Index transformations
While reindexing is in progress, your query may not return all matching results, if the queries happen to use the index that is being modified, and queries will not return any errors/failures. While reindexing is in progress, queries are eventually consistent regardless of the indexing mode configuration.
If you feel that None is safe step before going to Consistent, you are free to do so but it is not absolutely necessary.
I want to maintains user comments as an ordered list, based on the server write-time. A couple of questions regarding that:
Can I create (set / push) a locations based on ServerValue.TIMESTAMP?
Can I validate (1) with rules?
Can I safely assume that no two posts will be written at the exact "same moment", overriding eachother?
If I decide to use setWithPriority, and not order by the location-name, can I use ServerValue.TIMESTAMP for the priority (and validate it by rules....)
"Bonus" question - Is there still no way to create a COUNT query in firebase?
=== EDIT ===
I'm trying to achieve a chat-like feature. Messages must be ordered chronologically (by a server-side timestamp) in order to maintain a logical order for "discussion" (if I'll use a client-generated order than one local's machine clock offset could ruin the entire discussion). I can use rules to validate that a ServerValue.TIMESTAMP field is persisted to any new message, however, I can't seem to find a way to make sure that clients actually use setWithPriority() in order to persist data. I can't figure out any way to do this - am i missing something?
you can either .push() which generates auto ID as key or you can .setWithPriority() where your key can be anything and the priority can be pretty much anything as well. As far as I'm aware there is no option to have serverValue.TIMESTAMP as a key. The only way is to retrieve it and explicitly set it as the key with .child(retrievedTime).set(someData)
see 1)
Not sure what you mean exactly since there is no option to set servervalue as a key, but IMHO this is one of the reasons why is it so.
You can use some field on database and set ServerValue.TIMESTAMP and listen for the change - in the callback you will get the most current server time pretty much ASAP as the placeholder is replaced with TIMESTAMP. However there is no guarantee that it is going to be unique. It is perfectly legitimate to have to records with the same priority.
It is promised, but not yet available. You you can do it manually with transactions on every write/delete see docs
I watched a talk recently ( http://vimeo.com/68390507 ) where the speaker is very serious, saying several times, to never set EnableViewStateMac=false.
While using Enterprise Web Library, I noticed that EnableViewStateMac is set to false. What is being done in EWL to make up for this? How can I trust that it's secure?
It's important to note that while EWL currently has a dependency on Web Forms (and view state), it is a weak dependency, and our roadmap calls for eliminating the dependency entirely. EWL completely overrides the saving and loading of view state by using Page.SavePageStateToPersistenceMedium and Page.LoadPageStateToPersistenceMedium, and this means that it is impossible for any controls on the page to store their own [possibly insecure] state.
Here's the complete list of what EWL stores in view state:
EWL "page state". This is data that needs to persist for as long as a user stays on a page, but shouldn't be stored in a database or other durable storage. For example, the current item display limit of an EwfTable, or a form field value that needs to be saved on an intermediate post-back so that parts of the page can be refreshed. This type of data is directly manipulated by the user and not any more secret than run-of-the-mill form field values. In fact, we're considering storing it even more openly in hidden fields, which will enable JavaScript to manipulate it without post-backs.
A "form value hash". This is a hash of all form field values at the time the page was rendered. It is used on post-back to inform the user if any of the data changed under their feet since the last time they loaded the page. If this hash is hacked, two things could happen. First, the user could receive a "concurrency error" even if no data changed. Second, the user could not receive a concurrency error even if data did change. This second case may sound bad, but keep in mind that most web applications in the wild do not even have this type of concurrency checking in the first place.
The ID of the data-modification that failed on the last post-back. This is either null, empty, or equal to one of the post-back IDs present in the HTML of the page, and is used to re-run a data modification in certain cases, in order to re-display validation errors. The worst hacking outcome is that a different, but still triggerable, set of validation errors gets displayed.
It is not secure, unfortunately. The point of EnableViewStateMac isn't to prevent a control from round-tripping insecure state. It's to prevent an attacker from injecting his own state and having a control interpret it as valid.
EnableViewStateMac=false is an insecure setting. Full stop. No conditions, no exceptions, no excuses. Applications should never under any circumstance set this switch to false.
In fact, since there's no valid reason for an application to ever do this, we (the ASP.NET team) are going to forbid setting EnableViewStateMac=false in an upcoming version of ASP.NET. This may break applications which have been deployed with this setting. Normally we wouldn't do something that impacts compatibility so greatly, but the fact that we're making an exception here I hope demonstrates how serious we are when we say "nobody should ever do this."
Two questions: first, is it true that the only way to update '.priority' via REST is by using PUT, which forces you to rewrite all the other values? And I'm afraid to ask, but does that also apply to the Javascript SDK?
Second, is there maybe some other way other than using Priorities to order your collection 'server-side'?
Sorting things on the client doesn't work for me because I'm using a masonry-type plugin for layout which goes bonkers whenever the order changes client-side, but it seems to work fine server side. I'm using PHP to degrade the '.priority' value over time, lowering the item's position in the collection, but I'm forced to rewrite every other field at cron run. It works, but it would be better to just be able to update '.priority' or some other value that controls the position.
Question 1: .priority via REST API
You can set the priority without modify the record by calling PUT on the .priority directly. These examples are found in the REST API doc:
So, to reiterate, add .priority into the URL.
Question 2: Hacking masonry sorting in Angular using the data store?
If you haven't explored your options here, there are several libs dedicated to integrating masonry and angular which you may want to check out (e.g. angular-masonry). You may also have luck address sorting data in masonry directly, in its own SO question, rather than trying to solve it with your data store, which seems like an XY Problem.
The records in Firebase are sorted lexicographically, so you have three options:
name your items so they sort in the desired order
use push ids, which are ordered chronologically
use priorities to enforce a sort order other than the record id's natural sorting
Keep in mind that numeric keys, when mixed with lexicographic strings, cause behave strangely--err, by design--in Chrome. And, tangentially related, such a debate has waged that the ECMAScript standard will actually be changed to force them to correct it