I'm using Realm.io as database and I need a select * from all_tables in Realm.
I mean a method returning an RLMArray, but I have not found anything about this.
I need the class reference, such as Realm Browser.
Thanks.
You can use [realm.schema.objectSchema valueForKey:#"className"] to get an NSArray of all of the RLMObject subclasses used in the Realm.
I don't believe this is possible at the moment. You should request it on github. In the mean time you will have to create your own. First you have to know that an RLMArray can only hold one type so if in these different tables there are different types than you can not do the following. It would be as easy as creating your own method for this. It would consist of getting all objects from each table and just inserting them into the RLMArray; If your tables don't have the same type then you will have to use a NSMutableArray or an NSArray.
Related
I have a NSOrderedSet relaitonship on an entity. The order of the objects is correct until I save, quit and relaunch the app. Then, when the entity is fetched, For some instances of the entity, the order of this relaitonship is different from what it was prior to the relaunch. It's as if the NSOrderedSet completely forgot the order.
Inspecting the model file shows that this property is indeed ordered:
<relationship name="videoSegments" toMany="YES" deletionRule="Cascade" ordered="YES" destinationEntity="VideoSegment" inverseName="parentProject" inverseEntity="VideoSegment" syncable="YES"/>
I know about the autogenerated accessor code issue: Exception thrown in NSOrderedSet generated accessors however this is a different problem although it may be related somehow.
It doesn't forget anything, you should sort it. There is a difference between ordered and sorted.
Check NSMutableOrderedSet
If you need to return the data in a specific order, you need to add an attribute which defines the sort order, such as an index from 0..n, and sort the results on that.
CoreData doesn't pay any attention to the order in which you added the data
I'm having some problems storing a change to a complex object. I've done a lot of digging and can't figure this out for the life of me.
From debugging, I can clearly see that the object is correct before storing, but when I retrieve the stored data, it's empty(say the increase of a stat). Specifically here is the breakdown below
StatSheet has ArrayList of Players
Player has ArrayList of Stats
ArrayList of StatSheets -> ArrayList of Players -> ArrayList of Stats
The ArrayList of Stat objects doesn't store after a change is made, no matter what I do. The arraylist of players seems to update fine which confuses me. I have tried changing the update depth to 2, 3, 4, 5, and beyond. I have also tried specifically setting cascadeOnUpdate to true. Can someone please help, I've been at this for days.
It's been a while that I looked at db4o and you didn't give a lot of details about your environment or code but maybe you can look at these solutions:
Do you use web environment? So look at this first answer:
A few questions about working with db4o
Do you use 'commit' when you store your objects? Because after storing and updating process you should commit the changes.
The array list of objects is store but db4o don't know what to do with the inner objects. The ArrayList isn't 'Activatable', so you can't retrieve yours objects.
You must put activationPurpose on every getter/setter of your stored object to enable the activation of object.
As you can't do this on native java objects, DB4O provide you some objects that have been tagged with activationPurpose on there getter/setter : like :
com.db4o.collections.ActivatableArrayList
So every java collection that should be store must be replace with it db4o equivalent (com.db4o.collections.*).
I'll ask in the form of a hypothetical, which might make it easier for me to explain.
I have a class called Person, and in this has three fields:
NSString *name;
NSDate *dateOfBirth; and
NSMutableArray *friends.
An example object is this:
name = "John Smith"
dateOfBirth = 01/04/1985
friends = "Simon Scott"; "Jennifer Lane"; "Mary Firth"
Once the user has filled the NSMutableArray with the data they want, what would be the best way to save this data to the iPhone? I would anticipate that there could be up to 100 instances of the Person object, and all that will be required is the displaying of this data in a UITableView and giving the user the ability to add and remove entries at their will.
I have seen multiple suggestions on this site, which include NSDictionaries and using the writeToFile method, but before I research one of these, I was hoping someone could point me in the right direction? I would like to ensure that I'll be using the easiest and most appropriate method that's out there.
Many thanks.
Please take a look at the Property List Programming Guide. As long as you stick with a core set of object types for your data, you can write and read your data from a file or URL in one line, like this:
[people writeToURL:someURL atomically:NO];
The types you've mentioned in your question (strings, dates, arrays, dictionaries) can all be written to a property list.
#Achiral,
It really depends on what you want to do with the data and how concerned you are with the flexibility of your code.
However, my recommendation would be to use CoreData to make an SQLlite database and make a 'Person' entity with the properties that you list above. I don't know if you are familiar with CoreData, but it is highly optimized on iOS and is pretty easy to use, since it has a pretty simple 'fill in the blanks' style form for creating the data models. You should also note that CoreData is a well accepted and supported way to store data in an iOS and OS X app.
I hope this helps.
I would like to separate my reference data from my user data in my Core Data model to simplify future updates of my app (and because, I plan to store the database on the cloud and there is no need to store reference data on the cloud as this is part of my application). Therefore, I've been looking for a while for a way to code a cross-store relationship using fetched properties. I have not found any example implementations of this.
I have a Core Data model using 2 configurations :
data model config 1 : UserData (entities relative to user)
data model config 2 : ReferenceData (entities relative to application itself)
I set up 2 different SQLite persistent stores for both config.
UserData config (and store) contains entity "User"
ReferenceData config (and store) contains entities "Type" and "Item".
I would like to create two single-way weak relationships as below :
A "User" has a unique "Type"
A "User" has many "Items"
Here are my questions :
How do I set up my properties?
Do I need 2 properties for each relation (one for storing Unique ID and another to access my fetched results)?
Could this weak relationship be ordered?
Could someone give me an example implementation of this?
As a follow-on to Marcus' answer:
Looking through the forums and docs, I read that I should use the URI Representation of my entity instance instead of objectID. What is the reason behind this?
// Get the URI of my object to reference
NSURL * uriObjectB [[myObjectB objectID] URIRepresentation];
Next, I wonder, how do I store my object B URI (NSURL) in my parent object A as a weak relationship? What attribute type should I use? How do I convert this? I heard about archive... ?
Then, later I should retrieve the managed object the same way (by unconvert/unarchive the URIRepresentation) and get Object from URI
// Get the Object ID from the URI
NSManagedObjectID* idObjectB = [storeCoordinator managedObjectIDForURIRepresentation:[[myManagedObject objectID] URIRepresentation]];
// Get the Managed Object for the idOjectB ...
And last but not least, shouId I declare two properties in my entity A, one for persisting of URI needs and another for retrieving direclty object B?
NSURL * uriObjectB [objectA uriObjectB];
ObjectB * myObjectB = [objectA objectB];
As you can read, I really miss some simple example to implement thes weak relationships ! I would really appreciate some help.
Splitting the data is the right answer by far. Reference data should not be synced with the cloud, especially since iCloud has soft caps on what it will allow an application to sync and store in documents.
To create soft references across to stores (they do not need to be SQLite but it is a good idea for general app performance) you will need to have some kind of unique key that can be referenced from the other side; a good old fashioned foreign key.
From there you can create a fetched property in the model to reference the entity.
While this relationship cannot be ordered directly you can create order via a sort index or if it has a logical sort then you can sort it once you retrieve the data (I use convenience methods for this that return a sorted array instead of a set).
I can build up an example but you really are on the right track. The only fun part is migration. When you detect a migration situation you will need to migrate each store independently before you build up your core data stack. It sounds tricky but it really is not that hard to accomplish.
Example
Imagine you have a UserBar entity in the user store and a RefBar entity in the reference store. The RefBar will then have a fetchedProperty "relationship" with a UserBar thereby creating a ToOne relationship.
UserBar
----------
refBarID : NSInteger
RefBar
--------
identifier : NSInteger
You can then create a fetched property on the RefBar entity in the modeler with a predicate of:
$FETCHED_PROPERTY.refBarID == identifier
Lets name that predicate "userBarFetched"
Now that will return an array so we want to add a convenience method to the RefBar
#class UserBar;
#interface RefBar : NSManagedObject
- (UserBar*)userBar;
#end
#implementation RefBar
- (UserBar*)userBar
{
NSArray *fetched = [self valueForKey:#"userBarFetched"];
return [fetched lastObject];
}
#end
To create a ToMany is the same except your convenience method would return an array and you would sort the array before returning it.
As Heath Borders mentioned, it is possible to add a sort to the NSFetchedProperty if you want but you must do it in code. Personally I have always found it wasteful and don't use that feature. It might be more useful if I could set the sort in the modeler.
Using the ObjectID
I do not recommend using the ObjectID or the URIRepresentation. The ObjectID (and therefore the URIRepresentation of that ObjectID) can and will change. Whenever you migrate a database that value will change. You are far better off creating a non-changing GUID.
The weak relationship
You only need a single value on the M side of the relationship and that stores the foreign identifier. In your object subclass you only need to implement accessors that retrieve the object (or objects).
I would go with just one store.
For storing stuff in the cloud, you will anyway have to serialize the data, either as JSON or SQL statements, or whatever scheme you prefer.
You will need a local copy of the data on the user's device, so he can access it quickly and offline. The cloud store can have only the user entity, while the local store (part of the app) can also have the reference entity.
I have a similar project with a huge reference store (20000 records) with geographic information, and user generated content ("posts"). I use a single store. When I ship the app, the "posts" entity is also defined but empty. When I update the data model I simply re-generate the whole reference store before shipping.
I see absolutely no reason to go for a cross store solution here.
I'm new in iPhone development, can you advice me how to serialize AdressBook records?
I have read stackoverflow - How do I serialize a simple object in iPhone sdk, but I still have questions:
should I extend ABRecordRef? Is it possible? Or should I implement own class NSObject?
(similar question was on Mac forums and was left without answer)
Thank you!
ABRecord is an opaque C type. It is not an object in the sense of Objective-C. That means you can not extend it, you can not add a category on it, you can not message it. The only thing you can do is call functions described in ABRecord Reference with the ABRecord as a parameter.
You could do two things to be able to keep the information referenced by the ABRecord arround:
Get the ABRecords id by ABRecordGetRecordID(). The ABRecordID is defined as int32_t so you can cast it to an NSInteger and store it wherever you like. You can later get the record back from ABAddressBookGetPersonWithRecordID () or ABAddressBookGetGroupWithRecordID(). But aware, the record could be changed or even deleted by the user or another app meanwhile.
Copy all values inside the record to a standard NSObject subclass and use NSCoding or other techniques to store it. You will then of cause not benefit from changes or additions to the record the user could have made.
Of cause you can combine both approaches.