I'm rewriting a "Yelp for Dorm rooms" web app in Node/Express with a Parse backend (PHP version here for context).
Since I am very used to SQL databases, I have organized my data into four tables of one-to-many pointers:
Rooms
Halls
Clusters
Campuses
Every room has a pointer to its hall, each hall has a pointer to its cluster (a small group of halls) and each cluster has a pointer to its campus.
However, since each hall/cluster/campus has its own culture, I want to be able to search by each level (e.g. I want to live on South campus, or Norris Hall). However, since the pointers are nested three levels deep, I'm having a problem searching by campus and returning rooms. I'd hate to have to duplicate data and copy/paste cluster and campus data into each room object.
Searching for a cluster is easy. I can just:
var clusterQuery = new Parse.Query("clusters");
clusterQuery.equalTo("cluster", req.params.cluster);
var hallsQuery = new Parse.Query("halls");
hallsQuery.matchesQuery("cluster", clusterQuery);
query.matchesQuery("hall", hallsQuery);
So I figured doing a campus search would be simply
var campusQuery = new Parse.Query("campuses");
campusQuery.equalTo("cluster", req.params.campus);
var clusterQuery = new Parse.Query("clusters");
clusterQuery.matchesQuery("campus", campusQuery);
var hallsQuery = new Parse.Query("halls");
hallsQuery.matchesQuery("cluster", clusterQuery);
query.matchesQuery("hall", hallsQuery);
But of course, that would be too easy.
Instead, I get an error 154: Query had too many nested queries.
So my question for you, almighty Stackoverflow community: What should I do instead?
It makes more sense to name your classes with singular names, Campus rather than Campuses. So, I will go with singular names.
Your model is a tree structure and there are some patterns for it. The one you use is keeping parent references, that is simple but requires multiple queries for subtrees as you realized. Since Parse is using MongoDB, you can check use cases and model patterns of MongoDB, such as Product Catalog and Model Tree Structures.
Consider Array of Ancestors pattern where you have something like {_id: "Room1", ancestors: [pointerToAHall, pointerToACluster, pointerToACampus], parrent: pointerToAHall}.
You can find rooms where ancestors array contains a campus:
var query = new Parse.Query("Room");
query.equalTo("ancestors", aCampusObject)
Note that equalTo knows that ancestors is an array. You may want to check Parse docs for queries on array.
Related
I've been refactoring an existing Umbraco project to use more performant querying when getting back document data as everything was previously being returned using LINQ. I have been using a combination of Umbraco's querying via XPaths and Examine.
I am currently stumped on trying to get child documents using the Umbraco.ContentAtXPath() method. What I would like to do is get child document based on a path I parse to the method. This is what I have currently:
IEnumerable<IPublishedContent> umbracoPages = Umbraco.ContentAtXPath("//* [#isDoc]/descendant::/About [#isDoc]");
Running this returns a "Object reference not set to an instance of an object." error and unable to see exactly where I'm going wrong (new to this form of querying in Umbraco).
Ideally, I'd like to enhance the querying to also carry out sorting using the non-LINQ approach, as demonstrated here.
Up until Umbraco 8, content was cached in an XML file, which made XPath perfect for querying content efficiently. In v8, however, the so called "NuCache" is not file based nor XML based, so the XPath query support is only there for ... well... Old times sake, I guess? Either way it's probably not going to be super efficient and (I'd advise) not something to "aim for". That said I of course don't know what you are changing from (Linq can be a lot of things) :-/
It certainly depends on how big your dataset is.
As Umbraco has moved away from the XML backed cache, you should look into Linq queries against your content models. Make sure you use ModelsBuilder to generate the models.
On a small dataset Linq will be much quicker than examine. On a large dataset Examine/Lucene will be much more steady on performance.
Querying NuCache is pretty fast in Umbraco 8, only beaten by an Examine search.
Assuming you're using Models Builder, and your About page is a child of Home page, you could use:
var homePage = (HomePage) Model.Root();
var aboutPage = homePage?.Children<AboutPage>().FirstOrDefault();
var umbracoPages = aboutPage.Children();
Where HomePage is your home page Document Type Alias and AboutPage is your About page Document Type alias.
I am working on a service that provides information about a few related entities, somewhat like a database. Suppose that there's calls to retrieve information about a school:
service MySchool {
rpc GetClassRoom (ClassRoomRequest) returns (ClassRoom);
rpc GetStudent (StudentRequest) returns (Student);
}
Now, suppose that I want to find out a class room's information, I'd receive a proto that looks like so:
message ClassRoom {
string id = 1;
string address = 2;
string teacher = 3;
}
Sometimes I also want to know all of the students of the classroom. I am struggling to think which is the better design pattern.
Option A) Add an extra rpc like so: rpc GetClassRoomStudents (ClassRoomRequest) returns (ClassRoomStudents), where ClassRoomStudents has a single field repeated Student students. This technique requires more than one call to get all the information that we want (and many if we wanted to know information for more than one classroom).
Option B) Add an extra repeated Student students field to the ClassRoom proto, and B') Fill it up only when necessary, or B") Fill it up whenever the server receives a GetClassRoom call. This may sometimes fetch extra information, or lead to ambiguity according to what fields are filled up.
I am not sure what's the best / most conventional way of dealing with this. How have some of you dealt with this?
There is no simple answer. It's a tradeoff between simplicity (option A) and performance (option B), and it depends on the situation which solution is best.
In general, I'd recommend to go with the simple solution first, unless your measurements demonstrate that it leads to performance issues. At that point, it's easy to add repeated Student students to ClassRoom and a field bool fetch_students [default=false] to ClassRoomRequest. Then clients are free to continue using the simple API, or choose to upgrade to the more performant API if they need to.
Note that this isn't specific to gRPC; the same issue is seen in REST APIs, and basically almost any request/response model.
In v2 it was possible to make a call to /files with the query fileId in children to get a list of DriveFile objects that were parents of the supplied file.
Now, it seems to be required to make a call to /files/:fileId?fields=parents, then make a separate call to /files/:parentId for each returned parent, possibly turning one call into a dozen.
Is this correct, and if so why? This is a huge performance hit to our app, so hopefully there's an undocumented method.
The query "'fileId' in children'" doesn't publicly exist (not documented/supported) in v2 either and I don't recall it ever existing. What does exist in V2 is the Parents collection which effectively answers the same question. In v3, to get the parents of a file you just get the child and ask for the parents field.
As for whether or not that is a performance hit, I don't think it is in practice. The Parents resource in v2 was very light to begin with, and other than the ID the only useful field was the 'isRoot' property. That you can calculate yourself by calling files/root up front to get the ID of the root folder for that user (just once and save it, it won't change for that user.)
If you need to get more information about the parents than just the IDs and are worried about the # of calls you have to make, use batching to fetch them. If you just have one parent, no need to batch (it's just overhead.) If you find that a file has multiple parents, create a batch request. That'll be sent as a single HTTP request/response and is handled very efficiently on the back end.
Point is, if you just need IDs, it's no worse than before. It's one call to get the parents of a file.
If you need more than IDs, it's at most 2 HTTP requests (outside really bizarre edge cases like 1000+ parents which would exceed the batch size :)
In V3 it is possible to list all children of a parent as it's explained here: https://developers.google.com/drive/v3/web/search-parameters
Example call:
https://www.googleapis.com/drive/v3/files?q=parents in '0Byho0qAdzabmVl8xcDR1S0pNY3c' of course replace spaces with %20, this will list all the files in the folder which has id='0Byho0qAdzabmVl8xcDR1S0pNY3c'
you just need to mention like below:
var request = service.Files.List();
request.Q = "('root' in parents)";
var FileListOfParentOnly = request.Execute();
parse gives this example...
Internally, the Parse framework will store the referred-to object in
just one place, to maintain consistency. You can also link objects
using just their objectIds like so:
var post = new Post();
post.id = "1zEcyElZ80";
myComment.set("parent", post);
say i want to link a new comment to an existing post, how would i go about this? given i have the post objectId.
Ian, unless that target page was edited, your answer is incorrect. As per that page:
A good rule of thumb is, use a pointer for a one-to-one or one-to-many
relationship. Use a relation when you have a many-to-many
relationship.
It would seem there is some fuzziness in this area that many are not happy about.
Like I said in my comment, I prefer to set it up before hand in the parse data browser, but you would want to use a relation between the post and the comment not a pointer as I previously stated.
This is because a pointer should be used for a one-to-one relationship and a relation for a one-to-many relationship as a comment would be to a post.
https://parse.com/questions/pointer-vs-relation
This is in Java using Pointers to build relationship.
ParseObject favorite = new ParseObject("favorite");
myComment.put("parent", ParseObject.createWithoutData("post_id", "1zEcyElZ80"));
myComment.saveInBackground();
Currently I'm developing a debate module (much like a scrum/kanban board) for a GPL application (e-cidadania) and I don't have any experience with complex backends. I have developed a basic frontend for it, but now I don't know what approach I should use for the ajax and django backends to save and manipulate the table and notes.
The table can be N rows and N columns, every row and column has a name and position inside the table. Every note has also a position, text and comments (managed with the django comments framework).
I thought to store the parent element of every note (so I can place it later) and store the name of the rows and columns like CSV strings. Is that a good approach?
A screenshot of the current frontend: http: //ur1. ca/4zn4h
Update: I almost forgot, the frontend has been done with jQuery Sortables (so the user can move the note around as he likes) and CSS3.
You just need to model your domain (that is, debates that look like scrum boards) within Django. Think about it in plain English first, like this:
The has debates. These consist of criteria, organised in rows and columns in a specific order. This creates cells, which can have notes inside them.
Then you can set to work translating this into model classes. Don't worry too much about the fields they contain, the most important bit is the relationships (so the ForeignKey bits):
class Debate(models.Model):
title = ...
class Column(models.Model):
title = ...
order = ...
board = models.ForeignKey(ScrumBoard, related_name='columns')
class Row(models.Model):
title = ...
order = ...
board = models.ForeignKey(ScrumBoard, related_name='rows')
class Cell(models.Model):
column = models.ForeignKey(Column)
row = models.ForeignKey(Row)
class Note(models.Model)
text = ...
cell = models.ForeignKey(Cell)
That might be overly complex for what you need, though. I'm not an expert in the problem you're trying to solve? My suggestion, Django is quick – so start hacking, and give it a go, and if it's all wrong then you can go back a few steps, clean out your database and try again.
You might find it useful to play with South, which does database migrations for when you do things like add/remove/edit fields in your models.