I am currently adding Google Firestore in my app so I can store user preferences, licenses, and other metadata. I have Google Authentication setup as well so I can track whatever the user is registered or not.
Not being a database/NoSQL expert, any design suggestions would be greatly appreciated!
I need to store the following, and probably more later on:
App installation / license (multiple platforms: iOS, macOS, etc.)
Bought in-app purchases (for being able to restore them from another platform)
User preferences, so they can be re-used on another platform and for backup purposes
I am thinking of this simple design:
/users (collection)
|
+-- {user_XXXXXX} <- what should be used here? e-mail? generated ID?
|
+--- app_licenses (collection)
|
+ {license_XXX} <-- incremental id? auto-generated?
| |
| +-- platform : ios / macos / ...
| +-- installation_id : device id ?
+ {license_XXX} <--- incremental id? auto-generated?
| +-- platform : ios / macos / ...
| +-- installation_id : device id ?
|
+--- iap_purchases (collection)
|
+ {iap_XXX} <--- incremental id? auto-generated?
|
+-- name : unique identifier (title/name)
+-- transaction_id
+-- date : purchase date
+--- prefs
|
+ fav_color : red / blue / ...
+ another_pref : ....
Thank you!
Your design so far looks good to me.
Regarding your root user level: Do the user's your adding information for have to be logged in through firebase? If so, I would use the user's UID from firebase. It is guaranteed to be unique and can only be retrieved after authentication.
Here's a stack overflow question concerning that.
If you aren't necessarily storing users that are logged in through firebase, I would still use some kind of auto incremented id or GUID. Just make sure you avoid the possibility of duplicate id's being generated.
I would avoid using email because perhaps further down the road you might want to add multiple emails or even phone numbers as contact info.
As for the licenses and in app purchases: I'm not quite familiar with firestore, auto incrementing id's seems like only a SQL thing to me but if you have that available to you, I think that's acceptable. GUID's would also work.
Related
I am writing some user stories. I know I can use pesona instead of an Id which is not undrestandable for nontechnical persons. Consider following example:
Given I want to add "Alex" as user with Password "123" and description "blahblahblah"
When I register "Alex"
Then I should see "Alex" in the list of users with password "123 and with description "blahblahblah"
It is understandable but how Can I find "Alex" without a specific Id during acceptance tests?
If I use following scenario, It might not be understandable in one go and also for nontechnical people?
Given I have "Alex" data as following:
| Name | Password | Description |
| Alex | 123 | blahblahblah |
When I register "Alex" as user
Then users must be as following:
| Id | Name | Password | Description |
| 1 | Alex | 123 | blahblahblah |
What is the best way to be used instead of Id to be understandable for nontechnical and also be testable?
Consider the following, which may be a little more effective, though more verbose.
Given I am at registration
When I provide a name of Alex
And I provide a password of 123
And I provide a description of blahblahblah
And I register the user
Then the registered user should have a username of Alex
And the registered user should have a password of 123
And the registered user should have a description of blahblahblah
Some notes on reasons for my suggestion:
I grouped the when statements together as a logical action. I'm less concerned with having all of that in the given, especially if it's not as clear.
Behind the scenes, this should make your objects easy to set up - you can map the steps to setting values on local fields or a context.
I use "the registered user" because it strikes me as a "behind the scenes" detail for your users, especially if you're trying to avoid showing ID. In your step files, you can be looking for an ID of 1, but it doesn't seem like being the first/only user is specifically a part of this test.
If you prefer a table for the example data to show people, you could still parameterize the test:
Scenario Outline: My Scenario
Given I am at registration
When I provide a name of <usersName>
And I provide a password of <password>
And I provide a description of <description>
And I register the user
Then the registered user should have a username of <usersName>
And the registered user should have a password of <password>
And the registered user should have a description of <description>
Examples:
| <usersName> | <password> | <description> |
| Alex | 123 | blahblahblah |
Though I'm not sure I'd recommend it in this specific case, as to me it seems less explicitly readable in that format.
⚠ Side note: I think this is likely just an example, but please ensure you are not storing passwords in plaintext.
I have many view in Lotus Notes. What I want to do is I want to show only two view on web. So I'm just thinking using Frameset. I have a frameset with three frame. Below here example of my frameset.
--------------------------------------------------
| [HEADER] |
--------------------------------------------------
| [SIDE BAR MENU] | [CONTENT] |
| | |
| Draft | |
| Completed | |
--------------------------------------------------
I try to find in Internet but not found any example on how to display frameset in web. I'm still new with lotus web so please excuse me.
Also I am upgrading my company Lotus Notes system. Our old developer using "$$ViewTemplate for [viewname]" but it only show one view. I need to display two view in web. Anyone can suggest what else can I use other than this $$ViewTemplate? Any help I appreciate. Thanks!
Although this question is way to broad and lacks any kind of research I will try to push you in the right direction:
First: There is a frameset- design- element in designer... it simply works... just try it... Create it, put a Page or a Form in one of the frames (of course these need to be created before) and select it as default for the web (Properties of database) -> Voila
And second: you can use $$ViewTemplateDefault as a template for any view or just copy the existing one and give it another name like "$$ViewTemplate for OtherView" and it will simply work...
Best practice would not be to use framesets and classic notes web design elements but use more "modern" approaches as XPages (introduces in Domino 8.5 in 2008).
If you need to learn something totally new, then don't learn something that is outdated since more than 10 years...
I'm making a RoR app that is going to have a bunch of network diagnostic tools in it, like ping, traceroute, whois, etc. It's an internal company thing. Being that I'm learning Rails, I'd like to create it in that.
So, I'm curious what's the best structure to make this? Would it make sense to have all the tools under one MVC, like 'tools', or to break each one out into their own MVC (i.e., ping_controller & model/ping, traceroute_controller & `model/traceroute', etc.)?
So:
App
|--models
| |--tools (which would just write the `ip`, `tool_type` and `hitcount` to the DB.)
|
|--controllers
| |--tools (which would contain the methods: `ping`, `traceroute`, etc.)
|
|--views
|--tools
|--index.html.erb (which would have the individual form to run a given tool and show results)
Or would it make more sense to break it out more, but still keep the individual tool form elements on the same page and direct them with something like form_for(controller: 'ping', action: 'show'):
App
|--models
| |--ping (which would just write the `ip` and `hitcount` to the DB.)
| |--traceroute (which would just write the `ip` and `hitcount` to the DB.)
|
|--controllers
| |--ping (which would contain the normal CRUD and results)
| |--traceroute (which would contain the normal CRUD and results)
|
|--views
|--tools
|--index.html.erb (which would have the individual form to run a given tool and show results)
What's the "Ruby Way" to do this? I feel like the second option is not very DRY, but I'm still learning... hence my question.
If type is the only difference between each types of tools, I would suggest you to use the first way. If there will be more complex logic/columns differences, I would suggest you to have a look into Single Table Inheritance (STI):
http://samurails.com/tutorial/single-table-inheritance-with-rails-4-part-1/
I need help to map requests for vBulletin posts to their new location on a Drupal 7 forum.
I inherited a Drupal site after it was migrated from Drupal 5 with vBulletin, to Drupal 7 with native Drupal Forum + Advanced Forum. The new sit also uses PathAuto.
Every day I get many http requests using the old D5/vBulletin URL scheme, and there is no mapping in place to rewrite the target.
I believe I can use Apache mod_rewrite or Drupal Global Redirect to handle this, if I can map the old system to the new one.
For requests for "thread", e.g. example.com/forums/showthread.php?t=1 it seems possible to map, because the Drupal 7 path alias to the node for the thread has already been created using the existing node's title. So I can look up in the vBulletin database the old node title using the incoming query's 't' argument, edit that string according to the PathAuto settings in use on the new system, and create a URL alias. [Would love to know if there's a better way.]
But for incoming requests for "post", e.g. example.com/I can't see how to do it. The vBulletin database has the posts in the "post" table, but in Drupal 7 Forum anything after the initial post is a "comment" and has not had a URL alias created for it (because it doesn't have a title in vBulletin in most cases).
I suppose I could find the thread that the post belonged to and redirect the user to the top of the thread, as a workaround, but I'd like to have an accurate map.
Please any solutions for this ?
Drupal Migrate creates and saves tables in the database mapping the old resource ID to the new ID.
You just have to be careful since the schema are different between vBulletin and Drupal Forum; primarily in that Forum posts in D7 (other than the first post in a thread) are not nodes, but comments.
But I was able to use a Join SQL query to find the new resource ID:
mysql> SELECT m.sourceid1, m.destid1, c.cid, c.nid, c.subject FROM migrate_map_forum_posts m LEFT JOIN comment c ON c.cid = m.destid1 LIMIT 3;
+-----------+---------+-------+-------+-----------------+
| sourceid1 | destid1 | cid | nid | subject |
+-----------+---------+-------+-------+-----------------+
| 2 | 35837 | 35837 | 10426 | RE: Test |
| 3 | 35838 | 35838 | 10426 | |
| 4 | 35839 | 35839 | 10426 | I see a picture |
+-----------+---------+-------+-------+-----------------+
This solution only relies on the new Drupal 7 database and that's okay if the migration went perfectly (I guess if it was perfect the mapping would have been done at the time, lol). But the migration map tables don't always have all the data you need.
If you have access to the old vBulletin database you can dig deeper. In the migration that I inherited, some of the vBulletin 'posts' did not make it into the D7 migration map tables. But through doing more queries I was able to get the 'threadid' that the post belonged to from the vBulletin database and find the node ID for the Forum topic on D7 so I can at least get the user on to the right discussion.
Ever wonder what wikipedia's database schema looks like? I recently read this thread from reddit.
I like how their tables are tagged with a prefix so you can sort of tell its functionality, purpose, and relationship with other tables right off the bat.
One thing I do not notice is how they name their stored procedures. Do they even use SP?
I use MS SQL Server. Prefixing all stored procedures with USP_ or SP_ seems redundant and anti-beneficial as the object explorer already sorts it all out for me. How do you name your SPs?
I like how their tables are tagged with a prefix so you can sort of tell its functionality, purpose, and relationship with other tables right off the bat
That is why you have Schemas in SQL Server, you create a schema to group several object together and then you can give the HR person just access to the HR schema
Prefixing all stored procedures with USP_ or SP_ seems redundant and anti-beneficial as the object explorer already sorts it all out for me. How do you name your SPs?
SP_ should never be use because you will get a performance hit, whenever SQL server 'sees' a proc that starts with sp_ it will check the master database first, worst if MS decided to ship a proc with the sane name as yours and it starts with sp_ yours will never get executed
BTW not everyone is using the project explorer, some people like to do this in T-SQL
I personally will prefix my stored procedures with a unique name the describes what it does. For example.
SelectUserAccountById
or
InsertUserAccount
Typically the table name is referenced in the name, in the example above, the table would be UserAccount.
I do not prefix my stored procedures with SP or anything similar UNLESS I am building an extension that goes into a framework such as DotNetNuke, then I use a prefix for my company name.
I find it useful to name the strored proc as
TableName_Action
example RefClient_Insert, RefClient_Search, RefEmployee_Delete
This way, since the tables are grouped (Ref = Reference in this case) the SPs are grouped too.
Note that I have used _ just for clarity, you may skip it if you like.
I started naming all of the SQL objects with a widget type prefix. For example...
Photo Gallery Database Objects (abbreviated list)
Old Name | New Name
-------------------------------------------------
tblCategories | tblPGCategories
tblItems | tblPGItems
spGetCategories | spPGGetCategories
spUpdateCategory | spPGUpdateCategory
spGetItems | spPGGetItems
spUpdateItem | spPGUpdateItems
Event Calendar Database Objects (abbreviated list)
Old Name | New Name
-------------------------------------------------
tblCategories | tblECCategories
tblItems | tblECItems
spGetCategories | spECGetCategories
spUpdateCategory | spECUpdateCategory
spGetItems | spECGetItems
spUpdateItem | spECUpdateItems
We developed lots of websites and when a customer wanted a piece of functionalty we thought we could sell to others we would create it as a widget. We would then market these widgets to other customers.
This worked great until we started adding widgets we developed from other websites. We wound up with duplicate names for some of our code. So, out of necessity we implement a widget type naming convention. This made it very easy to integrate all the widgets we created.