Why do google has limitations in keys and values to 24 and 36 characters? What is the best implementation to overcome it.
https://firebase.google.com/docs/reference/android/com/google/firebase/analytics/FirebaseAnalytics.Param
Thanks!
Now you can log firebase analytics Event param name up to 40 characters and value up to 100 characters
See documentation here:
https://firebase.google.com/docs/reference/cpp/group/parameter-names
The main reason for the value size limits is to ensure minimal impact on the device battery, low device storage requirement, low network bandwidth usage and make the data more manageable for the infrastructure and BigQuery.
We might consider increasing the value limits if there is valid reasons to do so. What is the case where you need longer values?
Related
I have TTL set for 60 minutes. For the past 1 month or so it was working fine, records were deleted within less than 20 mins of TTL expiration. But lately (since this week) some (not all) takes up to 3 hours to delete after TTL expired.
I understand it can take a max of 48 hours, but my customer is asking for prove or justification to the current TTL behavior. Just saying IO workload influences TTL is not enough.
What metric can I use or look at to provide concrete evidence to current TTL's behavior? Is there any benchmark, eg IO load of N will cause N hours of delay.
Unfortunately there is no publicly available way to determine the time it will take for TTL to delete your items. The 48 hours isn't guaranteed either.
You'll find anecdotal evidence online regarding the behavior of TTL under different scenarios (e.g. large tables vs small, other processing happening in your account, etc.), but no official guidance that will answer the question your client is asking.
If your client is unsatisfied the ambiguity around TTL, perhaps they should be exploring other solutions like implementing delete in your application logic.
Working with the "new" Firebase Cloud Messaging, I would like to reliably save client device registration_id tokens to the local server database so that the server software can send them push notifications.
What is the smallest size of database field that I should use to save 100% of client registration tokens generated?
I have found two different libraries that use TextField and VarChar(255) but nothing categorically defining the max length. In addition, I would like the server code to do a quick length check when receiving tokens to ensure they "look" right - what would be a good min length and set of characters to check for?
I think this part of FCM is still the same as GCM. Therefore, you should refer to this answer by #TrevorJohns:
The documentation doesn't specify any pattern, therefore any valid string is allowed. The format may change in the future; please do not validate this input against any pattern, as this may cause your app to break if this happens.
As with the "registration_id" field, the upper bound on size is the max size for a cookie, which is 4K (4096 bytes).
Emphasizing on the The format may change in the future part, I would suggest to stay safe and have a beyond the usual max (mentioned above) length. Since the format and length of a registration token may also vary.
For the usual length and characters, you can refer to these two answers the latter being much more definitive:
I hasn't seen any official information about format of GCM registrationId, but I've analyzed our database of such IDs and can make following conclusions:
in most cases length of a registrationID equals 162 symbols, but can be variations to 119 symbols, maybe other lengths too;
it consists only from this chars: [0-9a-zA-Z\-\_]*
every regID contains one or both of "delimiters": - (minus) or _ (underline)
I am now using Firebase Cloud Messaging instead of GCM.
The length of the registration_id I've got is 152.
I've also got ":" at the very beginning each time like what jamesc mentioned (e.g. bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1).
I make the token as varchar(255) which is working for me.
However, the length of registration_id has no relationship with size
of 4k. You are allowed to send whatever size of the data through
network. Usually, cookies are limited to 4096 bytes, which consist of
name, value, expiry date etc.
This is a real fcm token:
c2aK9KHmw8E:APA91bF7MY9bNnvGAXgbHN58lyDxc9KnuXNXwsqUs4uV4GyeF06HM1hMm-etu63S_4C-GnEtHAxJPJJC4H__VcIk90A69qQz65toFejxyncceg0_j5xwoFWvPQ5pzKo69rUnuCl1GSSv
as you can see the length of token is: 152
I don't think the upper limit for a registration ID is 4K. It should be safe to assume that it is much lower than that.
The upper limit for a notification payload is 4KB (link), and the notification payload includes the token (link). Since the payload also needs to include the title, body, and other data too, the registration ID should be small.
That's what I understand from the docs ¯\_(ツ)_/¯
The last tokens I got were 163-chars long. I think it's safe to assume that they will never exceed 255 chars. Some comments in the other answer reported much higher lengths!
Update
So far, in 4 months that I'm running my app, there are over 100k registration IDs, and every single one of them is 163-chars long. It's very possible that Google maintains the ID length stable in order not to crash apps. Hence, I'd suggest
getting a few registration IDs in your local machine
measuring their length and verifying it's constant (or at least it doesn't change significantly)
picking a safe initial value, slightly higher than the ID length
I think it's unlikely for the length to change now, but I'll keep an eye. Please let me know if you noticed IDs of different lengths in your apps!
On the Stackdriver Trace documentation (https://cloud.google.com/trace/docs/quotas) I see there are Quota unit cost per API call, but that doesn't really tell me what the true API limits are.
For something like BatchWriteSpans the unit cost is 1, but it doesn't tell me how many or how large can my Spans be.
I would like to get more insight into the limits of the API and if there is anyway I can pull this information so that I don't have to hardcode these limits in my app.
The "unit cost" is just telling you how many of request-per-second quota units are used each request. As BatchWriteSpans has cost 1, you can make 4800 BatchWriteSpans each minute.
Below that are the limit on what can be in a request. For example, each span can only have 32 labels, each of which can be at most 128 bytes key and 256 bytes value.
There is no documented limit on the number of spans in BatchWriteSpans, but I'd assume it is the same as PatchTraces, ie 25000.
I need a sqlite3 database with over 1000 attached databases, but documentation says "The maximum number of attached databases cannot be increased above 125"
Some earlier versions talk about limit 63
Is this upper limit is artificial? I am able to compile sqlite after removing code that gives this limit, but is it safe?
We talk about limit because of performance or is there a deeper, hidden problem after crossing limit 125?
There are lots of deeper, hidden problems. For example, a cursor uses a signed 8-bit integer to hold the index of the database it refers to. 127 is the maximum value for a signed 8-bit integer.
In Firebase Realtime DB, what are the limits on:
keys
paths
nesting level
?
Meaning restrictions on lengths as well as disallowed/special chars/values.
And any other restrictions (or discouragements) there might be.
Is this deprecated pre-Google-integration document (link here) still up to date?
Length of a key: 768 bytes
Depth of child nodes: 32
I don't see max path length mentioned there.
What is the non-deprecated location for this documentation?
I cannot find an equivalent in https://firebase.google.com/docs/ .
As if some of the docs "got lost in the shuffle"...
Thanks for any hints.
EDIT: I've broadened it slightly - not just lengths but any restrictions that might apply.
The Firebase documentation says 768 bytes is still the limit for a Key, and that they use UTF-8 encoding. With UTF-8, a character is 1-4 bytes.
However, most characters are 1 byte, unless you use a character such as ♥, which is 3 bytes. Therefore, for normal use of a key, the character limit is 768. If you want to anticipate some outlandish characters, it may be best to be conservative and limit total characters to 500 ,600, or 700. Depends on how you want to use the keys.
Test your characters and strings here:
https://mothereff.in/byte-counter
Documentation here:
https://firebase.google.com/docs/database/usage/limits
This documentation mentions that firebase realtime database can be nested up to 32 levels. But as its mentioned there itself that it is not a good practice to nest your data. Denormalisation of data though seems redundant, it gives more flexibility when writing rules and when writing queries to the database.