Template using findOne is not consistently updating

1

I have one template (template A) using findOne to get a value that doesn’t consistently update upon another template (template b) using an insert function. Both templates and their js files reside in the client folder.

Basically I’m just using one template to display the last record in a collection and another template for a list view. The list view updates correctly, but the one displaying the single item updates a few times and then stops.

Any help?

2

Source code might be useful here!

3 
Template.a.helpers({
 'a':function(){
  return x.findOne({}, {sort:{_id:1}});
}
});

Template.b.helpers({
'b':function(){
 return x.find();
}
});
4

You sort by _id. You do realise this doesn’t work quite like auto increment in mySQL etc?
An ID in MongoDB is not completely guaranteed to be sequential. Especially if its accessed from client side.

If you have the _id field generation to random string generation (which I think is default?) You are absolutely not guaranteed getting it in order! If you use Mongo DB Object ID, the first bytes are a timestamp and can work for you, but can differ if set client side. So set it server side. Select the _id generator when creating the collection.
http://docs.meteor.com/#/full/mongo_collection

If you want to sort it properly by time, regardless of _id, use a server method and a timestamp.

x.insert({whateverdata…, created: moment().unix()}); //If you use the moment package.

5

No, I did not know that, thanks for pointing it out. I do have a createdAt field, I’ll give that a shot. I haven’t looked at moment yet.

6

It’s a common technique in a lot of DB systems. Also usable in mySQL and similar, but normally not by default. Often referred to as UID or GUID. (Globally) Unique IDentifier. MongoDB can generate this where the first bytes are related to a timestamp. Say that you have a user system. And you know your own postID based on the URL.
myapp.com/posts/edit?id=42
If this is sequential, you know that 41 exists. If you haven’t added security to protect against this, it’s quite easy to change the url to be able to edit it. However if you have an ID consisting of a more randomized identifier, guessing a valid one is close to impossible. An example ID from meteor default: dvfrbZ9Da5xgxXpEh
case sensitive alphanumeric with 17 characters in this case. That gives 62 possible symbols and 17 spaces. 62^17 is about 3 * 10^30. Of course you should check access right regardless, but it provides an extra level of security by making it impossible to guess IDs.

Try out Mongo.ObjectID instead perhaps as this is timestamp related and more likely to be sequential. It’s explained how you change in the other link I sent. However, it’s not guaranteed. The 4 byte timestamp can overflow after quite a few years ;). Best option is createdAt in any case. Created server side.
http://docs.mongodb.org/manual/reference/object-id/

ObjectId is a 12-byte BSON type, constructed using:

a 4-byte value representing the seconds since the Unix epoch,
a 3-byte machine identifier,
a 2-byte process id, and
a 3-byte counter, starting with a random value.