Collections and Schemas

So how about the aldeed:collection2 package? I see you’re making use of aldeed:simple-schema, but then show only how to validate manually.

Does the collection2 package still work with Meteor 1.3? Is its use recommended? Any disadvantages to validating automatically rather than manually?

1 Like

Is it still considered best practice to load the collection as a global variable?

1 Like

Negative - you’d want to import it wherever you use it. Like in the todos example app:

Exporting:

Importing:

@sashko I’ve been doing this recently, but now I can’t access that collection on the browser console. Is that supposed to be the case? Also, it seems slower which makes me feel like minimongo isn’t being used.

1 Like

It’s definitely not slower, it’s exactly identical to before.

If you want to access from the console I’d suggest putting a:

global.Lists = Lists

near where you export it.

1 Like

Interesting. I must be doing something else wrong, because it seems to be making the round trip call to the server db before updating my view. Thanks!

Did you import your methods on the client?

Yes, and tested that both the client and the server methods are being called. Can’t figure out where the latency is coming from, but only started happening today after I moved to modules.

Why is there no mention of Astronomy in the guide?

1 Like

@sashko Does Astronomy have some clashes or overlayed functionality with Apollo?

See the discussion here: https://github.com/meteor/guide/issues/10

At the end of the day we felt we had to make a decision so we picked simple schema.

You could at least mention that there is an alternative, since Astronomy is in some peoples (plural since I think there are more than me :slight_smile: ) view preferrable?

Probably a good idea to mention it at least, @tmeasday what do you think?

Yeah, we should mention it. I’m not sure what the best format is.

1 Like

Is the Lists.deny lines in the code above from Todos necessary? I thought all collections were deny by default as long as the insecure package is not installed.

Yes - if you read the text right next to it, it says that we add that so that nobody else can ever accidentally call allow on that collection.

Thanks for clarifying, but I must be blind because I don’t see the “accidentally” quote.

This is what I was referring to:

Is there some way we can make the text clearer?

Ohhhhhhhhhh wait I got totally confused. You were referring to the code snippet above from Todos. I was thinking of this section: http://guide.meteor.com/security.html#allow-deny

My mistake.

I have a ValidatedMethod that updates a collection document. Only the document author should be able to make updates. I tried to implement the editableBy helper from the todos example using dburles:collection-helpers as recommend in the Guide’s Collection helpers section.

const project = Projects.findOne({ _id: projectId });
if (!project.editableBy(this.userId)) {
  throw new Meteor.Error('Projects.methods.edit.unauthorized', 'Only author can edit a project.');
}

It kept failing and then I re-read the Errors in method simulation section.

ValidatedMethod turns on undocumented option in Meteor to avoid calling the server-side implementation if the simulation throws an error.

I realized that the findOne in my code above would only work on the server. On the client it would always return null and throw and error which would block the server code. As a fix, I just wrapped the above code with !this.isSimulation

How does the Todos example work, because it doesn’t use isSimulation?