Comments (13)
This appears to be the case even if the first query is @byId
but the second is a string path,. eg "users.#{userId}"
with a readPathAccess accepting that path - you only get the fields limited by the original query.
This is causing me problems. I want current-user and his friends store.query.expose 'self'
store.query.expose 'friends'
. For self
, I want the whole document - for friends
, only their public fields (name, status, etc). However, subscribing to both queries restricts both to the fields returned by friends
.
from racer.
This is a pretty important bug, hope it's fixed in 0.5. To reword what's happening in this bug, for all motifs defined on any given collection, only one motif's returned fields part will be honored. AFAIK it's the last motif to show up in a subscription / fetch.
This means you can't have public / private things in your app. IE, you can't have public / private users (self vs friends), public / private groups, etc - you just have to have public for everything, and only display the private fields in those cases, hoping the user doesn't know about DERBY.app.model.get
from racer.
AFAIK, 0.5 got rid of the ability to limit fields returned by a query, so this will no longer be relevant.
However, you may need to restructure some collections to preserve your functionality.
from racer.
goodness me... seems like then we'd have to replicate users into two collections, one storing all fields, one storing private fields :/
from racer.
Meh, that does seem cumbersome. Maybe they just haven't gotten around to re-implementing it yet?
from racer.
@psirenny I don't know.
@nateps, what plans do you have for fine-grained queries or access control?
from racer.
@SLaks is correct. only() queries (projections in MongoDB terms) are super buggy, and they are not practical to implement in Racer 0.5. The granularity of subscriptions will only be for individual documents or queries of multiple documents.
For now, you will have to store private fields in different documents. Read access control will only allow denying access to data at the document level in the first version. However, we eventually plan to implement the ability to filter a document on a per-client basis, as long as the same client always sees the same fields from a document. If data in other parts of the document change, the client will receive notice of version updates but strip out the blocked data.
from racer.
So if we used Twitter as a privacy example:
- self - can view / edit all fields
- friends - can view most fields, and send them messages (edit their messages field)
- public - can view basic info & tweets
Just to confirm: with 0.5, the only way to achieve this is by having 3 collections: usersPrivate, usersRestricted, usersPublic? Such that this:
model.query('users').withId(model.get('_userId')).subscribe (err, user) ->
model.ref '_user', user
becomes this:
uid = model.get("_userId")
priv = model.query('usersPrivate').byId(uid)
res = model.query('usersRestricted').byId(uid)
pub = model.query('usersPublic').byId(uid)
model.subscribe priv, res, pub, (err, part1, part2, part3) ->
model.ref '_user.privateFields', part1
model.ref '_user.restrictedFields', part2
model.ref '_user.publicFields', part3
from racer.
Yeah, you'll need to do something like that for the time being. Just for the record, if you only are getting one document from a collection, its more efficient to subscribe via the path and not a query in 0.5. Example in the 0.5 api:
userId = model.get '_session.userId'
private = model.at 'usersPrivate.' + userId
restricted = model.at 'usersRestricted.' + userId
public = model.at 'usersPublic.' + userId
model.subscribe private, restricted, public, (err) ->
model.ref '_page.user.private', private
model.ref '_page.user.restricted', restricted
model.ref '_page.user.public', public
from racer.
No longer relevant in 0.5
from racer.
However, we eventually plan to implement the ability to filter a document on a per-client basis, as long as the same client always sees the same fields from a document.
Strikes me that this will effectively be the same thing as projections, unless I'm misunderstanding?
from racer.
The difference is that projections mean you can create queries for different parts of your application that return different subsets of the same document. This is difficult to manage in ShareJS / Racer, since a client only has one snapshot of a document. If you were to do two different queries on the same document with different projections, we would somehow have to merge multiple projections of the same snapshot together. Since the different snapshots could be at different versions, this is not practical. We have no plans to implement this feature anytime soon, since you can simply structure your documents such that the amount of data returned is reasonable.
The access control filters will be different, because a client will only be able to subscribe to the exact same fields from a document. Thus, we don't have to worry about maintaining separate projections and merging them together. All we'll do is filter out the same properties every time we send a document or operation within a document to that client. If all fields in the update are filtered out, the client will still get notice of a version increase but not get the data. Note that we aren't implementing the access filter just yet, and access control has to be at the document level for now.
from racer.
I see, that makes sense now. Very informative, thanks Nate!
from racer.
Related Issues (20)
- query.ref can hang the browser
- Working example of angularjs app working with racer... for awhile HOT 1
- Immediate events break derby since racer 0.6.0-alpha43 HOT 1
- How can I use app.model.channel with new [email protected] HOT 6
- Exception in a model event subscription causes subscriptions break HOT 1
- Error message "Mutation on uncreated remote document" HOT 2
- State of Derby/Racer HOT 5
- Native iOS/Android version of Derby/sharedb
- setDiffDeep creates unnecessary ops when updating to the same scalar value
- Strange model set behaviour HOT 8
- Calling `setDiffDeep` from different models can set duplicate data on a given document in a race condition HOT 1
- If `cb` is undefined, `childModel.add` inputs for `segment` and `value` are incorrect HOT 2
- when items are removed from chained lists/refs, events fire twice HOT 4
- Add ability to fetch only if the data is not loaded HOT 1
- Dead project? HOT 2
- [dev] Upgrade from expect.js to Chai HOT 1
- [dev] Update to use Github actions HOT 1
- _splitPath function currently prevents the use of URL's as document identifiers (or any identifiers with . in) HOT 7
- Modern examples HOT 5
- `delPromised` requires path
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from racer.