I am developing an android app that allows users to create notes and save the notes in the android sq lite database.
The notes can contain elements I call UI elements, and each UI element has a corresponding table in the database and is linked to the 'note' table using the foreign key of the saved note.
Whenever the user saves a note, I save the note with all its elements in their appropriate tables.The user may choose to continue editing after a save action is performed.
Now, when the user tries to save again, I am presented with two options.
Delete the note record and related records (UI elements) from the database and save the note again (re-insert). I consider this an easier method.
Try and update the note table and tables related to the note, deleting UI elements that has been deleted and adding UI elements. I consider this as more tedious but logically correct.
I want to find out if there are any other methods that I can use to update an already saved record rather than these or if there is an improvement that can be made to these two models suggested.
Thanks.
Related
For example, Here is the data type,
User {
String name;
String lastName;
}
Now I'm storing this User class with Room and retrieving the list of all users with Dao
LiveData<List<User>> getAllUsers();
Now I want to add the Delete User functionality to it. And I also wanted to store all the deleted users in a separate table so that I can show them in a different place/Activity.
But I couldn't able to figure out what could be the better approach for this. Since the data type of deleted user is the same as User.
One way is to add an additional field into the User class and filter the list every time before displaying
User {
String name;
String lastName;
boolean deleted = false;
}
I just have to change the boolean value deleted when I delete the User object.
But I don't want to filter the list every time instead I want to store this deleted user in a separate table and this way I can retrieve the list of User and list of Deleted User much faster and save the time while filtering.
So how can I do this or is this the right way of achieving this delete functionality?
I guess there are two questions:
How to store two tables in Room Persistence Library of same data Type?
This question from your post' title
and
What is better - to store two tables or just one but to filter it?
I think this is the core of your question.
So,
1. How to store two tables in Room Persistence Library of same data Type?
The answer is simple. You should make two separate Room's entities, two separate DAO's for them (though you can use just one) and after deleting user you should in transaction delete it from one table and insert into another.
2. What is better - to store two tables or just one but to filter it?.
Of course, the answer is opinionated. You should consider all PROs and CONTRAs and make your choice.
Why to filter is better?
User and DeletedUser essentially are the same, they just has different status.
You don't need to duplicate the same fields in two tables. Otherwise you (and another developers who will maintain your app) should hold in mind that each change in User table (adding some field etc.) should be followed by the same changes in DeletedUser.
As usual Room's entities have id-s and they could be used in another entities as foreign key. As such you can't use User's id as foreign key, since after deleting it from User you can lose data in entities that are attached to it. In general, if User table is planned to have connections with another tables in app, then using separate DeletedUser is a bad way.
Why two tables is better?
As you've mentioned the filtered query might be slower. How much slower? That depends. For small tables (with up to 1,000 rows or even 10,000 rows) I guess you may not to see the difference. Still if you have some edge-case (enormous table) and struggle for performance really makes sense, you can choose that way.
P.S. Using Livedata in Room filtered result will be updated for you. So if you decide to use single table and one of the users in the table turns into delete-state, result will be updated without any special refresh-calls.
What is the best practice to store user data separately from the actual app data? The user data is a statistic and it will be collected during app usage. The database must be always updated but I have to keep the user statistic untouched. Can I store for example the statistic on one table? but can I keep this table when the App will be updated?
Update:
Sorry, I think my question was misunderstood. What is the best practice to manage two kinds of Data?
Save all data in one database and save the User-Data in seperetly tables? or
Create two Databases, one for App-data and one for User-data?
I'm not sure exactly of your question, but yes, you can have multiple tables in SQLite. So you can have one table for the user, call it tblUserStatistics and then other tables for the app, or depending on the data, the app information could be stored in preferences.
Yes, you can store your statistics in one table, but it's structure depends on what you want to save. If you want to save only numbers, you can create a table with 2 columns (1st one an ID and the second one the value you want to save), and update your rows when your data changes. If you've got multiple types of data to be saved (numbers, text, dates, whatever), you must create different columns with different data types, but still, you can do it. For your other questions the answer is yes, your table will be kept after you update your app, because it gets saved in a database which doesn't get modified when the user updates the app, just make sure that when you create the new version you don't change the name of the database.
I am writing an app which logs the GPS data in a database. Each time the user starts logging, I'd like to create a new table and save the data in that table. When the user stops logging, the table is closed. So the next time the user starts the app a new table should be created in the current database. How can I add tables dynamically to the current database?
In several different places I have read it is not a good idea to add tables or columns dynamically to a database. But why? and what is the solution?
Changing the schema dynamically makes data migrations you might want to perform on app update much harder. You'll also have to keep track of the created table names, which is doable, but probably completely unnecessary.
I'd say that what you really need is something like a session_id column in the GPS data table.
I am building an application which is a form generator (it creates a form with a SQLite database based on a configuration file). The problem is that the database will never be the same, so I need to make it dynamic meaning that I want to be able to specify all the table rows and tables of the database.
The problem I have is that, since it's a configuration file, when I create the database I dont know yet what are the tables and/or the table rows so I am not able to rely on the onCreate() of the database.
I was wondering if there would be a better way to proceed other than overriding the onCreate() to do nothing and making my own tableCreate() function.
I don't know if this is clear enough since english is not my native language but I will edit my question if I need to. And by the way I am new to android so snipet + explications are appreciated.
When the application loads, it creates the database using the configuration file (a simple text file) that is pushed to the application (only if the database does not exist).
Then it creates the tables based on the configuration file again (the name of the table rows and type of data).
The application builds the form based on the configuration file with an attribute which will allow me to save the answer in the database created previously.
This application's goal is to be able to create new forms efficiently and in a really quick way in order to gather some informations on given person.
Ok so I managed to build a workaround:
what I came up with is that I have a db with 4 fields (_id, farmerId, fieldName and fieldValue) this allows me to have some kind of value key for a specific farmer.
Then I builded some functions that generate a JSONObject with the different rows concerning a specific farmer and returns it to my activity. This way, it does not really matters if an "object" would need 5 or 6 fields.
I need to store an retrieve a vector of an unknown number of objects in an android sqlite database.
Essentially, the setup is this: I am developing a task management app, where the user can add as many notes as they like to their tasks. My current setup uses one database, with one row per task. This presents a problem when I need to associate multiple notes and their associated information with one task. I can see two approaches: try to store an array of notes or a vector or something as a BLOB in the task's row, or have another notes database in which each row contains a note and it's info, as well the id of the task which the note belongs to. This seems a little easier to implement, as all I would have to do to retrieve the data would be to get a cursor of all notes matching a particular id and then iterate through that to display them to the user. However, it seems a little inefficient to have a whole new database just for notes, and it makes syncing and deleting notes a little more difficult as well.
What do you think? Is it worth it to have a separate notes database? Should I use a BLOB or go for the separate database? If a BLOB, are there any good tutorials out there for storing and retrieving objects as BLOBs?
It sounds like you need another table in your database (not another database). You already have a table for Tasks. Now make one for Notes. Make a column be a foreign key into the Tasks table. That is, Notes.Task_ID would hold the ID of the Task that the Note is for. Then when you want to get all of the notes for a task, query the Notes table.
I think the answer to this question really lies in how you're going to go about updating things should they change. For now, the BLOB route probably seems like a really good idea, but what happens if you want to add some new functionality and you want to store some new property of notes (think of things like starred or importance). What would you need to do in order to update the notes object to add this new field? If it's just a database table, it's quite easy to change the layout of the table and even add a default value. If it's a BLOB, you're going to need to go through each entry, de-serialize the BLOB object, fix it, and re-serialize. That could get tricky.
Also, and this probably isn't as important to a small application using an embedded database, but it's easier to modify the database outside of the application if the object isn't a BLOB. Not to mention the queries you'll be able to write with the separate table. For example, how might someone calculate the number of notes that are attached to a task? If it's separated out in the database, it's a simple query.
Just my two cents.