I tried to update an array in a collection by doing
Configs.update({_id:this.parent._id, "cles.cle":this.context.cle},
{$set: {"cles.$.alias": $(e.target).val()}});
but I got this error
Uncaught Error: Not permitted. Untrusted code may only update documents by ID. [403]
How can I update data in an array, client side (minimongo) ?
OK, I think I finally understand the basis of your question. It looks like Meteor is treating your subselection of the array element in your selection criteria as an attempt to circumvent the policy of only allowing individual record updates. This feels like a bug in Meteor.
A possible work around:
var cles = Configs.findOne({_id:this.parent._id}).cles;
Modify the cles array as desired
Update the whole array in place Configs.update({_id:this.parent._id},{$set: {cles: cles});
Feels clumsy. Another solution would be to create a server method to do this on the server side. This would be better if your array can be large.
When you call collection.update on the client, the selector may point out docs by their _id field only. So you must do something like collection.update({_id: "your id"}, <updates>}) (or by using the alternative _id selector: collection.update("your id", <updates>})).
Related
Simple question:
Will all obersvers automatically removed when I use goOffline (disconnect to firebase) ?
If not, is there another way to do it, because removeAllOberserves doesn't seem to work or must I keep an array of single handles?
UPDATE
I answer myself.
removeAllOberserves works well, if you call it with the reference you used to set the observer!
Example:
Firebase *userThreadRef;
userThreadRef = [userRef appendPathComponent: ThreadsPath];
[userThreadRef observeEventType: FEventTypeChildAdded withBlock: ^(FDataSnapshot *snapshot) {
...
}];
....
[userThreadRef removeAllObservers];
Do not use a new reference like this:
Firebase *newUserThreadRef = [userRef appendPathComponent: ThreadsPath];
[newUserThreadRef removeAllObservers];
Will all observers automatically removed when I use goOffline (disconnect to firebase) ?
No. Calling goOffline() will not automatically remove observers/listeners.
is there another way to do it, because removeAllOberserves doesn't seem to work or must I keep an array of single handles?
It's hard to say without seeing your code, but likely your expectations are just wrong.
You'll need to call removeAllObservers() on each reference. The All in the method name is for the fact that it removes the observers for all event types, not for all references.
Currently it seems not to be possible to force a ready() state in the route. For example:
I have a waitOn on 2 subscribtions. One of them returns a Meteor.Error - now the route will be in the loading-state with no ending.
Is there a recommend way to tell iron-router "waitOn until subscribtion is ready OR subscribtion fails with an error" ?
Edit:
To explain my special case:
The waitOn is for a route which is for searching. The search arguments are "what" and "where". In "where" I have a plan String Address and need to convert it to a geo coordinate. For this I use the googlemaps converter on the Serverside (because its Sync). When no address was found I need to get back a error a lá "This address must be wrong". For this I need the functionality to get back an error.
When I do it like David Weldon said I need to do this step in the waitOn method but the Client-Side googlemaps converter is not Sync - instead its async so this would not work.
General Recommendations
It's okay for your publishers to throw errors, but those conditions should only be hit if the client does the wrong thing. In other words, you are solving the wrong problem - you should only subscribe when you know the publisher will not throw an error. Let's look at an example:
Suppose your route needs to subscribe to newPosts and postsForSuperuser. Assume that the postsForSuperuser publisher will throw an error if the user isn't a superuser. It's now the client's job not to let that happen. The waiton definition could look like:
waitOn: function() {
var subs = [Meteor.subscribe('newPosts')];
if (Roles.userIsInRole(Meteor.user(), ['superuser']))
subs.push(Meteor.subscribe('postsForSuperuser'));
return subs;
}
Because we are conditionally adding the postsForSuperuser subscription, we don't give the publisher the opportunity to throw an error.
Your specific use case
You case is a little more tricky, because mechanically the client is doing the correct thing but the user input may happen to be bad. In this case, I don't think throwing an error is appropriate. Here are some recommendations:
Avoid the problem by checking the address via a method call prior to changing the route.
If an address is found to be invalid, have the publish function immediately return this.ready(). This will prevent your route from failing, but you'll be left assuming that the reason you have no data is because of the address. If that's a valid assumption (i.e. it's the only possible reason for failure), then your router could deal with this by using a dataNotFound hook.
If you need to explicitly identify the cause of the error, have a close look at the 'counts' example from the docs. You can declare a client-only collection called addressErrors and then call this.added with a dynamically created document describing the cause of the error. The implementation of this is a little more tricky, and probably worthy of a separate question if you get stuck. I'd see if the first two make sense before attempting it.
In Meteor, I got a collection that the client subscribes to. In some cases, instead of publishing the documents that exists in the collection on the server, I want to send down some bogus data. Now that's fine using the this.added function in the publish.
My problem is that I want to treat the bogus doc as if it were a real document, specifically this gets troublesome when I want to update it. For the real docs I run a RealDocs.update but when doing that on the bogus doc it fails since there is no representation of it on the server (and I'd like to keep it that way).
A collection API that allowed me to pass something like local = true this would be fantastic but I have no idea how difficult that would be to implement and I'm not to fond of modifying the core code.
Right now I'm stuck at either creating a BogusDocs = new Meteor.Collection(null) but that makes populating the Collection more difficult since I have to either hard code fixtures in the client code or use a method to get the data from the server and I have to make sure I call BogusDocs.update instead of RealDocs.update as soon as I'm dealing with bogus data.
Maybe I could actually insert the data on the server and make sure it's removed later, but the data really has nothing to do with the server side collection so I'd rather avoid that.
Any thoughts on how to approach this problem?
After some further investigation (the evented mind site) it turns out that one can modify the local collection without making calls to the server. This is done by running the same methods as you usually would, but on MyCollection._collection instead of just on Collection. MyCollection.update() would thus become MyCollection._collection.update(). So, using a simple wrapper one can pass in the usual arguments to a update call to update the collection as usual (which will try to call the server which in turn will trigger your allow/deny rules) or we can add 'local' as the last argument to only perform the update in the client collection. Something like this should do it.
DocsUpdateWrapper = function() {
var lastIndex = arguments.length -1;
if (arguments[lastIndex] === 'local') {
Docs._collection.update(arguments.slice(0, lastIndex);
} else {
Docs.update(arguments)
}
}
(This could of course be extended to a DocsWrapper that allows for insertion and removals too.)(Didnt try this function yet but it should serve well as an example.)
The biggest benefit of this is imo that we can use the exact same calls to retrieve documents from the local collection, regardless of if they are local or living on the server too. By adding a simple boolean to the doc we can keep track of which documents are only local and which are not (An improved DocsWrapper could check for that bool so we could even omit passing the 'local' argument.) so we know how to update them.
There are some people working on local storage in the browser
https://github.com/awwx/meteor-browser-store
You might be able to adapt some of their ideas to provide "fake" documents.
I would use the transform feature on the collection to make an object that knows what to do with itself (on client). Give it the corruct update method (real/bogus), then call .update rather than a general one.
You can put the code from this.added into the transform process.
You can also set up a local minimongo collection. Insert on callback
#FoundAgents = new Meteor.Collection(null, Agent.transformData )
FoundAgents.remove({})
Meteor.call 'Get_agentsCloseToOffer', me, ping, (err, data) ->
if err
console.log JSON.stringify err,null,2
else
_.each data, (item) ->
FoundAgents.insert item
Maybe this interesting for you as well, I created two examples with native Meteor Local Collections at meteorpad. The first pad shows an example with plain reactive recordset: Sample_Publish_to_Local-Collection. The second will use the collection .observe method to listen to data: Collection.observe().
On my meteor project users can post events and they have to choose (via an autocomplete) in which city it will take place. I have a full list of french cities and it will never be updated.
I want to use a collection and publish-subscribes based on the input of the autocomplete because I don't want the client to download the full database (5MB). Is there a way, for performance, to tell meteor that this collection is "static"? Or does it make no difference?
Could anyone suggest a different approach?
When you "want to tell the server that a collection is static", I am aware of two potential optimizations:
Don't observe the database using a live query because the data will never change
Don't store the results of this query in the merge box because it doesn't need to be tracked and compared with other data (saving memory and CPU)
(1) is something you can do rather easily by constructing your own publish cursor. However, if any client is observing the same query, I believe Meteor will (at least in the future) optimize for that so it's still just one live query for any number of clients. As for (2), I am not aware of any straightforward way to do this because it could potentially mess up the data merging over multiple publications and subscriptions.
To avoid using a live query, you can manually add data to the publish function instead of returning a cursor, which causes the .observe() function to be called to hook up data to the subscription. Here's a simple example:
Meteor.publish(function() {
var sub = this;
var args = {}; // what you're find()ing
Foo.find(args).forEach(function(document) {
sub.added("client_collection_name", document._id, document);
});
sub.ready();
});
This will cause the data to be added to client_collection_name on the client side, which could have the same name as the collection referenced by Foo, or something different. Be aware that you can do many other things with publications (also, see the link above.)
UPDATE: To resolve issues from (2), which can be potentially very problematic depending on the size of the collection, it's necessary to bypass Meteor altogether. See https://stackoverflow.com/a/21835534/586086 for one way to do it. Another way is to just return the collection fetch()ed as a method call, although this doesn't have the benefits of compression.
From Meteor doc :
"Any change to the collection that changes the documents in a cursor will trigger a recomputation. To disable this behavior, pass {reactive: false} as an option to find."
I think this simple option is the best answer
You don't need to publish your whole collection.
1.Show autocomplete options only after user has inputted first 3 letters - this will narrow your search significantly.
2.Provide no more than 5-10 cities as options - this will keep your recordset really small - thus no need to push 5mb of data to each user.
Your publication should look like this:
Meteor.publish('pub-name', function(userInput){
var firstLetters = new RegExp('^' + userInput);
return Cities.find({name:firstLetters},{limit:10,sort:{name:1}});
});
everybody.
I have a doubt in this portion of my system: I want to encrypt some messages from users to the database and decrypt them when showing back to the users (that's just for privacy reasons). Since I couldn't find any native encrypt/decrypt library or even a better solution, then I am using the "crypto-js" (https://code.google.com/p/crypto-js/), and it's working well so far. The problem is: when the user write a message I encrypt it and save it at the database. But when I retrieve that message from the database using the "find" method in a Template Helper (using the reactive computation idea to approach the desired "Live HTML"), what I get is just a cursor that will be used to render the message in my HTML. As you can see, the message is shown without be decrypted.
I was thinking in "fetch" the data from the cursor, run the decrypt function in a "for loop" over all messages, but that's too inefficient.
I was wondering if someone know how may I manipulate the data from the cursor before it be render, then I'll be able to decrypt each message on the fly.
Really thanks for your attention and sorry any bother.
You could use a transform function. The transform is passed as the cursor is used so it only runs on each document as it is used:
YourCollection.find({}, {transform:function(doc) {
var encrypted = doc.field1;
doc.field1 = decrypt(encrypted)
return doc;
});
So now each field1 would be decrypted (on the web browser). Just before it was used. If you use .fetch() you would get all the decrypted data too.
You didn't posted the related code here, but I assume you have done something like this:
Template.yourTemplate.yourHelper = function(){
return yourCollection.find({});
}
The thing is your are returning the data to the helper, in form of cursor, which is perfectly acceptable in general. But as you are storing encrypted messages in collection, each message is rendered as it is without performing decryption.
So, try to fetch an array instead of cursor using find().fetch() which gives the array equivalent of your cursor. Something like :
Template.yourTemplate.yourHelper = function(){
var msg_arr = yourCollection.find({}).fetch(); // gives array instead of cursor.
msg_arr.forEach( function( msg ){
// traverse through each element of array and
// perform decryption.
});
}
I just had a talk at the #meteor IRC channel and some ideas came out. And I thought that this one is the best solution for my case:
{{#each messages}}
{{decrypt}}
{{/each}}
As helpers get the data from the context, the helper "decrypt" got the actual "message" in the loop as a "this" object. Then, I did the decryption and returned the message in plain text.
It works pretty well, further it is called reactively and make use of the cursor (that is update dynamically if data changes during the exhibition).
Thanks everybody whom helped me.