We're planning on saving the twilio call ids on our side for specific reasons. For efficiency, it would better for us to store them as uuid instead of varchar.
From our tests, the call ids we are getting are 34 characters long and start with 'CA'. We want to know if this is always the case.
Is it safe for us to store the 32-character id (without first two characters) in our database as uuid? Will this be unique?
So, I contacted Twilio support since we were really avoiding storing the ids as varchar. And as mentioned, there's nothing in the documentation about the id.
Turns out they say it's safe to store the last 32 characters. So we'd be able to save it as uuid and it'd be more efficient when saving, fetching records.
Haven't found any info in the docs so my sugestion is. DON'T DO IT.
If it's not specified in the docs that the "accountsid" is unique without the letter (CA), then they are free to not have them unique.
Maybe it works, maybe it keeps working, but one they it may not work and you are going to spend lots of resources hunting down the bug. Then you will regret not saving the full 34 characters long line just to save a few bytes.
Related
I'm making a simple Swift meditation app and want to have a feature to allow users to see how many others have installed the app as well ("You're part of a community of 354 other meditators")
My current plan - save a "blank" record on first load to public DB in CloudKit.
Then - each client on login retrieves all the records and counts how many there are?
Is there a better solution. I could imagine this getting slow if there are lots of users...
Thanks!
In terms of your CloudKit example, as far as I'm aware there is no option to return the number of records, instead CloudKit just returns the actual records in batches (it decides how many to return). However, you may specify a limit of records for it to return.
If you did specify a limit, you would need to continually update it since once the number of records grows larger than the limit it will no longer retrieve them all and your count will be wrong.
This would be a bad idea probably since you will have to continually release app updates to increase the limit (unless you stored this value in some kind of other external DB which would then probably be preferable to CloudKit itself). Basically, CloudKit is probably not the best idea for this.
It would probably be much easier to use a different public DB setup. Either set up your own or use a service like 'Parse.com' which makes setting up and connecting to a public DB very simple. An additional benefit of doing it this way is you can run the count query on the server and just return the count value itself rather than returning all records and counting them locally - very inefficient.
Is there an option in DynammoDB to store auto incremented ID as primary key in tables? I also need to store the server time in tables as the "created at" fields (eg., user create at). But I don't find any way to get server time from DynamoDB or any other AWS services.
Can you guys help me with,
Working with auto incremented IDs in DyanmoDB tables
Storing server time in tables for "created at" like fields.
Thanks.
Actually, there are very few features in DynamoDB and this is precisely its main strength. Simplicity.
There are no way automatically generate IDs nor UUIDs.
There are no way to auto-generate a date
For the "date" problem, it should be easy to generate it on the client side. May I suggest you to use the ISO 8601 date format ? It's both programmer and computer friendly.
Most of the time, there is a better way than using automatic IDs for Items. This is often a bad habit taken from the SQL or MongoDB world. For instance, an e-mail or a login will make a perfect ID for a user. But I know there are specific cases where IDs might be useful.
In these cases, you need to build your own system. In this SO answer and this article from DynamoDB-Mapper documentation, I explain how to do it. I hope it helps
Rather than working with auto-incremented IDs, consider working with GUIDs. You get higher theoretical throughput and better failure handling, and the only thing you lose is the natural time-order, which is better handled by dates.
Higher throughput because you don't need to ask Dynamo to generate the next available IDs (which would require some resource somewhere obtaining a lock, getting some numbers, and making sure nothing else gets those numbers). Better failure handling comes when you lose your connection to Dynamo (Dynamo goes down, or you are bursty and your application is doing more work than currently provisioned throughput). A write-only application can continue "working" and generating data complete with IDs, queueing it up to be written to dynamo, and never worry about ID collisions.
I've created a small web service just for this purpose. See this blog post, that explains how I'm using stateful.co with DynamoDB in order to simulate auto-increment functionality: http://www.yegor256.com/2014/05/18/cloud-autoincrement-counters.html
Basically, you register an atomic counter at stateful.co and increment it every time you need a new value, through RESTful API.
thank you for taking the time and interest reading this and hopefully helping me out.
I need an unique user identifier for IOS, and what I mean with unique user identifier is a unique string that Apple provides that is unique for user not device, meaning that it will stay the same across devices. I thought about the Apple ID or something like that, but it´s not possible, because Apple does not provide it(at least not that I know of), but I want something similar to that.
It cannot be the UDID, because(besides being deprecated) it´s not persistent across devices. I want this in order to authenticate a user, without the user having to login, or signup. It is possible to do so, because some apps do so. I didn not log in or anything with another device, but it authenticated me. I had thought it was with the Apple ID, but that´s not possible to do.
I checked this answer: iOS unique user identifier. And it seems that it might be the solution, but I don't quite get it, as I don't see how it would be unique to every new user(being able to distinguish between multiple users, and the same user, but on different device).
I really appreciate people reading this and trying to help.
Thank you
PD: I use Titanium´s Appcelerator, not Apple´s IOS SDK or anything like that. But it´s not that important, I just want to get the process to be able to do it with Titanium's Appcelerator
PS: NOTE:
Thank you for answering and so fast!. I have read it many times and I just don't get it. Could you guys help me understand it a little bit better?
The way I understand it is this.
1.-Create an UUID(changes with every installation)
2.-Store it to the Keychain(As far as I know, the values saved on the keychain are local to the device) with a default service(I think Ill put it with the application's id-com.bla.bla-), and also a default account, I think Ill leave it as "users".
This will all be local, so every single installation will do this, with a different UUID for each installation(not necessary every user)
3.-Save the UUID to the NSUserDefaults.
4.-Save the UUID to the Cloud's public data store.(The UUID in the Cloud´s Data Store, Keychain and NSUserDefaults should be the same)
So, if 5 installations are run, the Cloud´s Public Data Store should be like this
An Array of 5 values:
[
XXXX-EEEEE-FFFFF,
SFSDFFWE-WERW-SDFS,
XXXX-XXXXX-XXXXX,
ZZZZZ-ZZZZ-ZZZZX,
XZXZZX-ZXZXZXS-ADADS
]
5.-All this will be executed every time you run the application, checking first if there is a value stored on the public cloud store. Here´s where I am confused, how will a different device know which UUID is yours? I mean, there are 5 different UUIDS to chose. Maybe it´s not supposed to be saved on the public data store, but on the private data store, but for that you would need to also identify each user. This is where I get so confused.
If there is no UUID set, execute the last 4 steps.
So, I get confused on the 5th step, most people understand that solution, without any more explanation, so I must be ignorant in the way something works, maybe the cloud services? I think the problem is that maybe I'm not understanding how the iCloud works, and how it stores it´s values. I just don't get how the 5th(random number, it might be the 2nd or 2000th) device of X running the app, will know that the UUID XXX... is the UUID of user X, and not the UUID of user Z.
Thank you again for answering so fast, I thought maybe I would have to wait a couple of days, not a couple of minutes. Forgive me for my ignorance, I'm kind of a noob on this matter, but I would like to learn. Been stuck on this problem for days
The answer you referred to is the correct way to identify your users. The solution is to save the value of that identification called a UUID (Unique User ID) - as opposed to a UDID (Unique Device ID).
The only down side to this of course for you as a developer is that the user could delete and install the app again and have a different ID.
As Daniel said, the UUID is the correct way to identify your users. I just want to add on this; you said that
I dont see how it would be unique to every new user
Well, accordint to this Wikipedia article:
Randomly generated UUIDs have 122 random bits...only after generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%. The probability of one duplicate would be about 50% if every person on earth owns 600 million UUIDs.
So you can be pretty sure that the UUID will be unique to each user.
Additionally, the MAC address is based off of the MAC address of your ethernet card, the timestamp, and some other miscellaneous information. This adds to the uniqueness of the UUID as according to this question on Superuser:
[MAC addresses] are reasonably unique.
The first 3 octets define the manufacturer.
The last 3 octets are usually generated at the time of PROM burning. It's up to the manufacturer how they do this.
That obviously gives 16,777,215 possible unique MAC addresses per manufacturer. That's quite alot, so the manufacturer shouldn't re-use one.
So basically, the UUID adds an additional degree of uniqueness to the MAC address.
In summation, for your intents and purposes, the UUID would be perfect.
Hope this helps!
So, we have a very large and complex website that requires a lot of state information to be placed in the URL. Most of the time, this is just peachy and the app works well. However, there are (an increasing number of) instances where the URL length gets reaaaaallllly long. This causes huge problems in IE because of the URL length restriction.
I'm wondering, what strategies/methods have people used to reduce the length of their URLs? Specifically, I'd just need to reduce certain parameters in the URL, maybe not the entire thing.
In the past, we've pushed some of this state data into session... however this decreases addressability in our application (which is really important). So, any strategy which can maintain addressability would be favored.
Thanks!
Edit: To answer some questions and clarify a little, most of our parameters aren't an issue... however some of them are dynamically generated with the possibility of being very long. These parameters can contain anything legal in a URL (meaning they aren't just numbers or just letters, could be anything). Case sensitivity may or may not matter.
Also, ideally we could convert these to POST, however due to the immense architectural changes required for that, I don't think that is really possible.
If you don't want to store that data in the session scope, you can:
Send the data as a POST parameter (in a hidden field), so data will be sent in the HTTP request body instead of the URL
Store the data in a database and pass a key (that gives you access to the corresponding database record) back and forth, which opens a lot of scalability and maybe security issues. I suppose this approach is similar to use the session scope.
most of our parameters aren't an issue... however some of them are dynamically generated with the possibility of being very long
I don't see a way to get around this if you want to keep full state info in the URL without resorting to storing data in the session, or permanently on server side.
You might save a few bytes using some compression algorithm, but it will make the URLs unreadable, most algorithms are not very efficient on small strings, and compressing does not produce predictable results.
The only other ideas that come to mind are
Shortening parameter names (query => q, page=> p...) might save a few bytes
If the parameter order is very static, using mod_rewritten directory structures /url/param1/param2/param3 may save a few bytes because you don't need to use parameter names
Whatever data is repetitive and can be "shortened" back into numeric IDs or shorter identifiers (like place names of company branches, product names, ...) keep in an internal, global, permanent lookup table (London => 1, Paris => 2...)
Other than that, I think storing data on server side, identified by a random key as #Guido already suggests, is the only real way. The up side is that you have no size limit at all: An URL like
example.com/?key=A23H7230sJFC
can "contain" as much information on server side as you want.
The down side, of course, is that in order for these URLs to work reliably, you'll have to keep the data on your server indefinitely. It's like having your own little URL shortening service... Whether that is an attractive option, will depend on the overall situation.
I think that's pretty much it!
One option which is good when they really are navigatable parameters is to work these parameters into the first section of the URL e.g.
http://example.site.com/ViewPerson.xx?PersonID=123
=>
http://example.site.com/View/Person/123/
If the data in the URL is automatically generated can't you just generate it again when needed?
With little information it is hard to think of a solution but I'd start by researching what RESTful architectures do in terms of using hypermedia (i.e. links) to keep state. REST in Practice (http://tinyurl.com/287r6wk) is a very good book on this very topic.
Not sure what application you are using. I have had the same problem and I use a couple of solutions (ASP.NET):
Use Server.Transfer and HttpContext (PreviousPage in .Net 2+) to get access to a public property of the source page which holds the data.
Use Server.Transfer along with a hidden field in the source page.
Using compression on querystring.
I have a rails app that tracks membership cardholders, and needs to report on a cardholder's status. The status is defined - by business rule - as being either "in good standing," "in arrears," or "canceled," depending on whether the cardholder's most recent invoice has been paid.
Invoices are sent 30 days in advance, so a customer who has just been invoiced is still in good standing, one who is 20 days past the payment due date is in arrears, and a member who fails to pay his invoice more than 30 days after it is due would be canceled.
I'm looking for advice on whether it would be better to store the cardholder's current status as a field at the customer level (and deal with the potential update anomalies resulting from potential updates of invoice records without updating the corresponding cardholder's record), or whether it makes more sense to simply calculate the current cardholder status based on data in the database every time the status is requested (which could place a lot of load on the database and slow down the app).
Recommendations? Or other ideas I haven't thought of?
One important constraint: while it's unlikely that anyone will modify the database directly, there's always that possibility, so I need to try to put some safeguards in place to prevent the various database records from becoming out of sync with each other.
The storage of calculated data in your database is generally an optimisation. I would suggest that you calculate the value on every request and then monitor the performance of your application. If the fact that this data is not stored becomes an issue for you then is the time to refactor and store the value within the database.
Storing calculated values, particularly those that can affect multiple tables are generally a bad idea for the reasons that you have mentioned.
When/if you do refactor and store the value in the DB then you probably want a batch job that checks the value for data integrity on a regular basis.
The simplest approach would be to calculate the current cardholder status based on data in the database every time the status is requested. That way you have no duplication of data, and therefore no potential problems with the duplicates becoming out of step.
If, and only if, your measurements show that this calculation is causing a significant slowdown, then you can think about caching the value.
Recently I had similar decision to take and I decided to store status as a field in database. This is because I wanted to reduce sql queries and it looks simpler. I choose to do it that way because I will very often need to get this status and calculating it is (at least in my case) a bit complicated.
Possible problem with it is that it get out of sync, so I added some after_save and after_destroy to child model, to keep it synchronized. And of course if somebody would modify database in different way, it would make some problems.
You can write simple rake task that will check all statuses and, if needed, correct them. You can run it in cron so you don't have to worry about it.