I have entityA and entityB that have a one-one relationship between them (entityA.a = entityB).
My question is: if I set entityA.a = entityB, then insert entityA, will entityB automatically be inserted?
I think it should be, but it looks like it's not.
Does that mean I should insert entityB myself?
By the way, I know I should call insert myself for a one-to-many relationship.
No, it won't be inserted. A relation is a link between two existing entities, you should first insert both entities and set de relation after.
Related
I’m an Android developer working with back4app.com
Assuming there are two classes. Class1 and Class2.
Class1 has a relation column to Class2.
I need to query Class1 and find the rows which their relation column, contains a specific Class2 object. The specific Class2 object is available.
I think that one way is to fetch all rows of Class1, and check if the relation column contains that specific Class2 object for each row. But I believe it is the worst-practice possible :)
So is there any other way to achieve this in android?
Something like this should work:
ParseQuery query = ParseQuery.getQuery("Class1");
query.whereEqualTo("theNameOfTheRelationColumn", theClass2Object);
You can see more details about Many-To-Many relations here.
I have some kind of this table.
The question is what is the best way to create this kind of table?
Should I create for each item one table is it possible to create only one table??
Updated: See comments under #Emil.
You should have 1 tables as #Emil has suggested.
This should look like, soemthing like
_id, sort, grade, diameter, length, price1_dol, price1_euros, price2_dol, price2_euros, final,
Note: I have split up prices columns up - so you have price1_dol, price1_euros, price2_dol, price2_euros.
It is indeed possible to make this data into just one table. The columns sort and grade seem to uniquely identify one row so together they might make up a candidate key. If so you could use those as your primary key, or create a new integer column that you use as the primary key.
You should definitely not create one table per item. The database schema should never change with normal use. Only when you add, remove or change the type of data you have in your database should you consider changing the schema. Otherwise you should design and normalize your database in such a way that it's possible to grow the data only by inserting new rows, not new tables.
I have EntityA and EntityB. EntityA has a to-many relationship with EntityB.
I have several EntityB objects that have been set as related (children) to EntityA. How can I delete that relationship without deleting any of the Entity objects?
Try the following:
EntityB entityB = myEntityBDao.load(id_entityB);
entityB.setEntityA(null);
entityB.update();
This just deletes the relation and modifies entityB, but a formerly related EntityA should not be deleted or even modified.
I'm quite new to Android and the SQLite. I'm currently working on an app which requires user to create list of their favourite artists.
I have implemented some charts which already display this artist data. I believe I can easily figure out how to implement adding data to lists.
I was thinking of having two separate tables in SQLite :
Lists (which would store the list names which the user has created)
ChartItems (which would store the chart items and the lists they belong to)
However the Lists table only needs one field in this case "ListName" so I thought it might not be crucial to have a table for this.
Is it possible to dynamically create tables when getting input from a user?
For example : A user creates a list and that value is subsequently used to create a table.
Thanks.
You don't want to be creating new tables on the fly. Your proposal for two tables is fine. The list table should have at least two fields - an integer field called id or _id which is the primary key, and a text field for the list name. The Chartitems table will have a field (listid) which holds the id of the list to which it belongs. This means a chartitem can belong to only one list, and adding a chartitem to a list is achieved by setting the listid field in its record. This is a one-to-many relationship.
If you want to have a single chartitem in more than one list, then you need a many-to-many relationship, which is implemented by having a third table (links). This table will have one field mapping to a list (listid), and one field mapping to a chartitem (itemid.) To add a chartitem to a list, you create the appropriate link entry in the links table. In this case the chartitem table does not need the listid field.
I suggest reading up some more on relationships in databases to clarify these concepts. One principle I strongly suggest following is to have every table contain a field called id which is the primary key for that table, and use that for all references from other tables. In the long run this works much better than using other fields (like name) in relationships.
I'm new to greenDAO and I'm working on writing the DaoGenerator. One issue that I've run into is that I have a user table and a wallpost table. I would like to be able to have two columns in the wallpost table that are toMany relations to the user table (the wall owner and the posting user) they may or may not be the same user, but so far it doesn't look like it is possible to have two toMany relations that point to a single table in the same table.
Is there a better way to do this/a way to make this possible? I'm hoping to be able to load the wall posts and fetch the wall owner and posting user by calling .getOwner() and .getPoster().
Thanks
You must set names for the relations. Have a look at the (just improved) section called Relation Names and multiple Relations of the documentation on relations. It comes with an example:
Property pictureIdProperty = user.addLongProperty("pictureId").getProperty();
Property thumbnailIdProperty = user.addLongProperty("thumbnailId").getProperty();
user.addToOne(picture, pictureIdProperty);
user.addToOne(picture, thumbnailIdProperty, "thumbnail");