Here's the situation. I have a bunch of objects that implement Serializable that I want to store in a SQL database. I have two questions
Is there a way to serialize the object directly into the database
Is that the best way to do it or should I
Write the object out to a formatting String and put it in the database that way and then parse it back out
Write each member to the database with a field that is unique to each object
Its generally not a good idea to try and put any sort of object (serialized/deliminated) in your SQL because modifying them is always a bitch.
It sounds like you're on the right track with idea 2. Is this a one-to-many situation? (because then a xref would obviously be the right answer) or even a foreign key would be better. cheers.
I'd still have a table per class + simplistic DAO.
If you absolutely want to do it wrong :), then serialize to JSON and persist the resulting string.
You could store the objects directly using db4o:
http://www.db4o.com/Android/default.aspx
Related
I have an app already in production, and now I want to change database property names in several tables to reduce bandwidth.
For eg, realtime database existing property is:
purchasePrice: 60
and by using #PropertyName, I want to change it so it now looks like this:
pp: 60
The changed POJO now has #PropertyName like:
#PropertyName("pp")
public float purchasePrice;
The question is: What is the best migration strategy so that all existing 'purchasePrice' is updated to new name in the realtime database, i.e 'pp' in this example case?
One naive approach I can think of is, on app update at client end, pull all data using old POJOs and assign each property to new POJOs (newPOJO.pp = oldPOJO.purchasePrice) and then save it in DB. But there should be a better way, as I have many POJOs.
Thanks,
If you want to change the name of a field in the database everywhere it occurs, there is really no easy way to do this. You're going to have to:
Query all of the nodes where it could appear
Check to see if the field needs to change
Write the new data back to that location
Whether you do that with code that uses #PropertyName or something more generic, it doesn't really matter.
I am trying to create sqllite db for my Android application use
Is it bad habit to have all the data types as text? The reason is even though some data can be integer in nature (like number of items.. Etc) but many times I need to display the values as a string or get it as input from user. So I thought for easier manipulation I will just make the datatype in the db as text
Thoughts?
The first thing to understand here is SQLite Storage Classes. SQLite allows any data type to be stored in a table's columns, the actual data type defined by the table is just a hint to the database engine.
This means that even if you define a column as type INTEGER, you can still store text in it.
That being said, I haven't found a use case for storing arbitrary data types in a column, or a case for disregarding the defined data types. For readability purposes, it would probably be a good idea to type things properly and obey the defined types.
I'm trying to think of how to get around this problem. I have an ORMlite object that can belong to multiple Categories; I'm using another table (i.e. a ForeignCollection) to track many-to-many connections between my objects and categories.
The problem is if I update the object with changed categories, the new categories are added, but old ones are not removed.
In the JavaDoc for the update method of DAO I see this text:
NOTE: Typically this will not save changes made to foreign objects or
to foreign collections.
My question is about the use of the word "typically." Does this mean that there IS a way through some sort of setting to make sure that updates update related foreign objects/collections?
Or should I read the sentence as if "typically" was not there, assume there is no automatic method, and that I need to run extra queries on committing each object to delete old categories?
The problem is if I update the object with changed categories, the new categories are added, but old ones are not removed.
So you have an object that has a foreign collection of categories:
#ForeignCollectionField
ForeignCollection<Category> categories;
If you run categories.add(category1) or categories.remove(category1), then the underlying collection should remove those from its associated table using a built-in DAO.
If you are changing the category list some other way then you are going to have to remove the Category entries by hand using the categoryDao directly.
... about the use of the word "typically." Does this mean that there IS a way through some sort of setting to make sure that updates update related foreign objects/collections?
Not sure why I left the word "typically" there. I think it was a blanket statement to take into account the various auto-create, auto-refresh, etc. field settings -- I'm not sure. In any case, I've removed it from the code base.
ORMLite has no way to know if foreign objects have been changed. It does not create magic proxy objects nor sessions so that it can tell when a foreign object has been updated. You have to be explicit about what you want updated when. The documentation on foreign collections is quite explicit about it.
OrmLite will not save objects to ForeignCollections automatically. You have to store and delete these objects yourself. Ormlite will retrieve the objects in the ForeignCollection automatically for you, provided you set the right parameters in the annotation.
Ormlite is "lite". It does ORM, but not completely. It's not JPA or Hibernate.
I solved this problem by adding the new Category to the table Categories directly, instead of adding a new category to the Object's foreignCollection.
This can be done by simply creating a category ado and adding a new element.
A newCategory.setObject(object) is needed in order to create the relation with the object.
Hope this helps.
I have following scenario. There is OrderHeader and OrderDetail tables in SQLLite database. I have Activity where I want to display that data. There is number of fields...
The way I see it - it has to be like this:
Get data from my content provider (I have it).
Get ordinals for columns in cursor.
Get values from cursor and format/assign them
Like I said - there is MANY fields and writing this kind of code (especially #1 and #2) very tedious and boring :)
So, I've got this idea.. Since my data comes in as JSON to begin with (from web) - I can store original JSON presentation in database along with parsed-out data and when I need to bind - all I need is to query table for this column and deserialize with GSON. This way - #1 and #2 will be 3 lines instead of many. And I will work with POJO...
Does that sounds good or there is natural nice way to bind views to data from database?
Use a ListView and a SimpleCursorAdapter (or extend it).
I'm using a SQL database to store a single float value, and I'm really having trouble getting my brain around everything that needs to be done to make it work. I've been reading the NotePad tutorial Google provides for a few days now and Googling around but it just isn't clicking in my head.
Could anyone explain to me (no code needed) just what exactly I need to have for a simple database, and how to read the value from it into my float variable and how to write the value of the variable back to the table?
Much thanks, I think my brain is starting to seep out my ears.
A SQL database is not a very good way to store a single float value. It's overkill. Instead, I recommend just using Android's SharedPreference class, which provides a simple key-value store.
If you're still going to create a database, what you need is:
The database file.
A SQL schemea for that database file. This describes the tables in the database, as well as the columns. If you're just storing a single float, then you could just create a single table ("data"), with two columns ("key", "value") -- like SharedPreferences, we're just implementing a key-value store of our own (another reason not to do this -- you're reinventing the wheel).
Once that's created, you can just insert a record with some arbitrary key ("myFloat") for lookups later and your chosen value.
So, your initial SQL statement would look something like this:
INSERT INTO data (key, value) VALUES ("myFloat", 3.14);
Later, you'd retrieve it with a SELECT statement:
SELECT key, value FROM data WHERE key="myFloat";
And you can update the value with an UPDATE statement:
UPDATE data SET value=3.14 WHERE key="myFloat";
It is as simple as shown above or just try reading more on SQL queries