First login?
Lost password?
 
 
 
General mailing list for discussions and development of PeerLibrary and related software.

List archive Help


Re: [PeerLibrary dev] PeerDB vs. Meteor collection queries


Chronological Thread 
  • From: Mitar < >
  • To:
  • Subject: Re: [PeerLibrary dev] PeerDB vs. Meteor collection queries
  • Date: Tue, 05 Aug 2014 01:03:57 +0200
Hi!

> 1) What's the benefit of using PeerDB instead of Meteor collections?
> The ability to track/include references seems to be very useful but was
> this the main reason for picking PeerDB?

PeerDB is abstraction on top of Meteor collections. It tries to address
multiple things, mostly the question of how to do references among
documents and migrations.

I think I explain quite well the issue of references here:

https://github.com/peerlibrary/meteor-peerdb#references

Read also:

https://www.discovermeteor.com/blog/reactive-joins-in-meteor/

Many things are easy in Meteor, but because of that the main
complications is how you define publish endpoints (what you push to the
client) and then how and when you subscribe to that. Most of complicated
logic is then there. For example, it becomes really complicated when you
have multiple related documents and you have to publish based on them.
One typical example is, pushing publications based on person's
permissions. As permission changes, you have to push different publications.

> 2) Querying the server's DB is straightforward in Meteor [1]; you simply
> run something like
>
> Publications.find(...)
>
> (here Publications would be a standard Meteor collection). With PeerDB,
> a query of the form
>
> Publication.documents.find(...)
>
> only seems to query the documents that are available on the client side.
> Is there a way to query the server's DB?

No, those two calls are for now exactly the same. In PeerDB they are
wrapped in our functions so that in the future we can do some pre- and
post- processing, if needed.

The question of what is available on the client side you solve with
publish endpoints and subscriptions and is orthogonal to the question of
queries. You probably have some other issue in between why first query
works for you and second does not.

> 3) The realization of the publication search in peerlibrary confused us.
> This is how we understand the process works:
> a) client/search.coffee: currentSearchQuery is updated in the Session

Yes.

> b) client/results.coffee: on change of currentSearchQuery,
> the Meteor endpoint 'search-result' is subscribed with the query
> string.

Yes.

> c) server/search.coffee: search is carried out

Yes.

> d) what happens next? Is the client's Publication list then updated
> by the server?

Server pushes two types of documents to the client. One is a list of
publication documents, that is, search results themselves. Each of those
publications have a special additional client-only (not stored in the
database) field searchResult which points to the second pushed document,
SearchResult instance. SearchResult instance is used on the client to
determine which of all publications available on the client belong to
the given search query.

You can see the code for that here:

https://github.com/peerlibrary/peerlibrary/blob/development/server/lib/search.coffee

Then, there is one more layer, which filters only those publications
current user has access to, and pushes only them to the client as search
results.

> 4) Are the global variables (such as Publication) defined for debugging
> purposes or are they actively used?

They are actively used all around the code. This is the main way how you
access data, through documents classes.


Mitar

--
http://mitar.tnode.com/
https://twitter.com/mitar_m

Archive powered by MHonArc 2.6.18.

Top of page