I have notice a new property - retrievedEntities on the breeze.QueryResult object.
Googling only turned up this -
https://github.com/Breeze/breeze.js/commit/7eb5deda8dfcff83ddf5a2cecf39ae21a9266a9b
Which is a check-in with comment
"Added retrievedEntities property to results object returned by
entity…"
On another note - how do I view the full entire check-in comment on github?!
The retrievedEntities property is an array of all the entities that were returned by the query. This will differ from the results property when your query uses .expand() to get related entities. For example, the object returned by the query
var query = EntityQuery.from('Orders')
.take(20)
.expand('Customer, OrderDetails');
would have a results property that is an array of 20 Order entities; each Order would have its associated Customer and OrderDetail entities attached to it in a graph.
The retrievedEntities property would be a flat array of all Order, Customer, and OrderDetail entities. This may or may not be useful, depending on what you are doing with the query results.
Thanks for the reminder to update the documentation!
P.S. The full comment is there in the github commit, but the second line is in a very small font (and very brief).
Related
I am trying to use SharkORM to fetch relationships across my objects. I am familiar with the joinTo syntax defined in SharkORM's documentation, but I am not sure how to use the resulting joinedResults object to get the related objects I need.
[[Person query] joinTo:[Department class] leftParameter:#"department" targetParameter:#"Id"]
outputs
{
"Department.Id" = 61;
"Department.location" = 35;
"Department.name" = Development;
}
into the Person.joinedResults field, but how do I take those results and get a Department object back. I've tried making a call to person.department after the joinTo, but it seems to make a second query to the database as if I hadn't used joinTo at all.
Am I really expected to parse the dictionary results of person.joinedResults into a Department object manually? That is very cumbersome, especially when you start joining more than one relationship.
I feel as if I am missing some obvious way to use the results of the joinTo.
The join functionality is in addition to relationships. So you can reference unrelated (or related) tables in a query, but then objects you get back can only ever be physically structured as per your original class, and are defined from the data and not from your query.
So, in a nut shell; joinTo: will enable you to reference remote or unrelated objects in your query for selection.
But to traverse object relationships you would use the properties.
Person* p = GetFirstPerson()
// reference/traverse the object to look at relationships (1:1)
p.department
or
p.department.location
So I guess what i'm saying is, even though it is SQL like syntax, you can only ever end up with rigidly defined classes in a fixed structure as a result unless using other interfaces such as sum, distinct etc..
There are at least 2 main collection types used in Realm:
List
Results
The relevant description from the documentation on a Results object says:
Results is an auto-updating container type in Realm returned from
object queries.
Because I want my UITableView to respond to any changes on the Realm Object Server, I really think I want my UITableView to be backed by a Results object. In fact, I think I would always want a Results object to back my UI for this reason. This is only reinforced by the description of a List object in the documentation:
List is the container type in Realm used to define to-many
relationships.
Sure seems like a List is focused on data modeling... So, being new to Realm and just reading the API, I'm thinking the answer is to use the Results object, but the tutorial (Step 5) uses the List object while the RealmExamples sample code uses Results.
What am I missing? Should I be using List objects to back my UITableViews? If so, what are the reasons?
Short answer: use a List if one already exists that closely matches what you want to display in your table view, otherwise use a Results.
If the data represented by a List that's already stored in your Realm corresponds to what you want to display in your table view, you should certainly use that to back it. Lists have an interesting property in that they are implicitly ordered, which can sometimes be helpful, like in the tutorial you linked to above, where a user can reorder tasks.
Results contain the results of a query in Realm. Running this query typically has a higher runtime overhead than accessing a List, by how much depends on the complexity of the query and the number of items in the Realm.
That being said, mutating a List has performance implications too since it's writing to the file in an atomic fashion. So if this is something that will be changing frequently, a Results is likely a better fit.
You should use Results<> as the Results is auto updating to back your UITableView. List can be used to link child models in a Realm model. where as Results is used to query the Realm Objects and you should add a Realm Notification Token so you know when the Results are updated and take necessary action (reload table view etc.) Look here for realm notifications: https://realm.io/docs/swift/latest/#notifications
P.S. The data in that example is just static and no changes are observed
I am new to Core Data and am attempting something which seems to be simple but is elusive to me.
Entity: Person
Attribute: First Name
I would like to fetch all First Name attributes but only have each one show once. That means that if "Peter" exists 5 times it would only be fetched once.
I could fetch all "First Name" attributes and then iterate through it and compare all first names but this seems so clumsy. Is there a faster, more elegant way?
Coredata provide a property to get distinct Results. Use as below:
request.returnsDistinctResults = true
Is it possible in realm to query for objects that have the same property value?
Imagine a list of contacts with firstname and lastname. I want to query all contacts that have the same name and may be duplicates in the db.
As far as I'm aware, there's no automatic way to do that with NSPredicate (Of which Realm implements); it would need to be done manually.
That being said, it should be relatively trivial to do manually; simply loop through each object, performing a query that searches for that object's name properties, and see if the number of results returned is greater than 1.
That being said, depending on how big your data set is, this could become a very slow operation very quickly. Ideally, you might be better off ensuring that duplicate entries don't occur, or if they do, to somehow index them so they're easier to look up.
I am using Parse as the backend for an app I'm working on. I was wondering if there is an optimal algorithm to query for only 'unseen' new objects.
What I am planning on doing is something like adding a user to the viewed object's relation and later querying all objects to check for the absence of the user. This seems to be O(n* all users who have seen an 'n') complexity which is a bit too much.
Another way to do this is to add the object to a user's key 'seen' and to then query for all objects the user has not seen.
Maybe a much more efficient way could be (assuming I view these objects chronologically) is to mark the first and last objects I see, and only show ones before or after those points using the createdAt key. Then I guess to show new objects outward from those points to not have to divide into multiple queries.
Ideally I'd like to shuffle through the objects, but I also would like to keep this algorithm as efficient as possible.
Create a Class called View. Each View consists of a unique identifier from a viewable Object (CANNOT BE THE OBJECTID) and a pointer to the User that viewed the object.
Your query should be:
//(Simple equalTo query)
Query1 = All View Objects where User pointer = User
//(whereKey:that-unique-id-column doesNotMatchKey:that-unique-id-column inQuery:Query1)
Query2 = All viewable Objects where not included in pointers in Query1