In my "book" application I want to have:
1. A universal account--to handle text and other data all users will see
2. A user account--to handle the user's personal data (bookmarks, etc.)
How is this done? I see in the docs, "Accounts and Authorization," descriptions of both, but it seems to describe it as either universal or user; I need both simultaneously.
Thanks!
Hi Pebah,
Have you considered solving this with your data model instead?
The universal account can be replaced by a table. You can have a "universal" table that will store the text and other data the users will see.
The user account can be managed by the cdbUsers table. You can added keys to the users table for the user's personal data, like a "bookmarks" key. After a user signs in, you can use function cdb_readUsersByEmail(pEmail) to get their user record and access their personal data from there.
- Efrain
We do not recommend the method using two accounts. The only way to do this would be to use two projects for one app. You would have to hardcode your developer credentials in your code so you can use cdb_sdk() to switch between projects. This is a security vulnerability.
The desired behavior can be acheived by using separate tables in the same project. Let me explain.
A newly created project has 2 tables by default, the cdbBlobs table and the cdbUsers table. The cdbUsers table contains a record for every user of this project. In your case, it will have a record for every users of your book app.
Let's say we were to create a "universal" table in this project. When you export the toolkit to your app, the book app will be aware of all tables in this project, including the "universal" table and the cdbUsers table.
When a user signs in you can get their user record using function cdb_readUsersByEmail(pEmail) and store it locally so you can access their personal data whenever you want.
You mentioned the "universal" data would be updated often. You have a couple options for this: cdb_sync() with "local" reads or stricty "cloud" reads.
You can perform "cloud" reads on the "universal" table so your user always sees what's on the cloud. Using "cloud" reads will be the closest to realtime data but will be less performant. (This might be the best solution for you if you're ok with the performance of the "cloud" reads)
Or when a user signs in, you can use function cdb_sync(pRecordIDL, pTable, pSource, pAllowDeletes, pDetectCollisions) with "cloud" for pSource on the "universal" table. This will download the current data on the cloud so it can be accessed locally. Using sync with "local" reads will be more performant but there's a chance the user can see stale data if anything on the cloud changes after the sync is called. You can perform this sync as often as you like so your user doesn't see stale data but it will affect performance.
Your app will have both the universal data and the user data so you can use them both as desired when a page is flipped.
Hi JereMiami,
No, a developer must be authed to move between projects using cdb_sdk(). cdb_sdk() can still be used if a user is authed but it has to be on the current project.
One additional thought when syncing is to sync specific records. You do not have to sync the entire table.
- This makes the transaction more performant
- You improve security by only syncing data relevant to that user's data in the cdb_users table.
You can store their cdbRecordID to their cdb_users table in a local table, so you do not have to query for that data on every run of your app.
Working with the data locally, as Efrain said, is the most performant method possible. Should your app crash, or the client lose internet access, their data is store locally. The next sync will pick up the changes and send them to the cloud when conditions allow.
