Comments (10)
I should add that neither of these really solves the dynamic issue of adding new required fields while the app is running...though the second one might be able to be modified to do it better since those variables are only valid within the current run of the method call.
from meteor-collection2.
Could you please provide us with sample code illustrating the empty object issue you run into?
from meteor-collection2.
So, I'm not terribly concerned about the error at this moment. I'm more trying to see if there might be a way dynamic schema with validation was intended to happen that I'm not getting from the documentation.
But since you asked, as for the error, it happens when I try to insert items on startup (which I desperately want to do when I launch this update to our app so they do not all have to be entered manually). However, if I make a minor change to any file and have the app reload in development, it works. The oddest part about this is I am passing "validate: false" as an option, yet it still clears the object.
var success = Document.insert(data, {selector: {type: projectID}, validate: false});
Essentially I have collections file where I am declaring the default schema for a document type. However, custom fields can be added to this document type based on the project the document belongs to. So when I go to add a document it checks for all the custom fields that have been added to that project and extends the schema like so:
CustomSchema = new SimpleSchema(extendSchema); Document.attachSchema(CustomSchema, {selector: {type: projectID}});
from meteor-collection2.
This looks like something where you should be checking the input against the schema directly, instead of attaching these to the global shared collection with selectors
from meteor-collection2.
This looks like something where you should be checking the input against the schema directly, instead of attaching these to the global shared collection with selectors
I'm not quite sure what you mean. I need to validate the document to be inserted both with the common schema as well as the fields specific to the project the document belongs to. My goal is to receive one error message that would include all invalid fields in both the common schema as well as the fields specific to the project.
from meteor-collection2.
Either keep attaching new schemas to the collection with a different selector like you've been doing or just like @coagmano recommended handle this issue at schema level without getting the collections involved. And as I understand from your previous comment you had already dabbled with the first solution but it's not working for some reason. This is why I'd always prefer a simple repository where we can tinker with solutions having a concrete problem to solve.
Anyway, deciding which solution to go for depends on your use case. If you already know what new fields you need to validate and there're not many of them (i.e. not many projects with their own specific fields) then you can simply attach multiple schemas at the collection initialization and you'd be good to go. But if you actually somehow dynamically decide not only the fields to validate but rather what those fields are then stick with schema validation level.
Collections solution:
// collection.js
const Documents = new Mongo.Collection('documents');
const basicDocumentSchema = new SimpleSchema({
id: String,
name: String,
documentType: String, // will be used later to pass to different docuemnts
});
const defaultDocumentSchema = basicDocumentSchema.extend({
defaultDocumentField: String,
});
const specialDocumentSchema = basicDocumentSchema.extend({
specialDocumentField: String,
})
Documents.attachSchema(defaultDocumentSchema, {selector: {type: 'default'}});
Documents.attachSchema(specialDocumentSchema, {selector: {type: 'special'}});
// method.js
...
Document.insert(doc, { selector: { type: doc.documentType }})
Schema solution:
// method.js
const basicDocumentSchema = new SimpleSchema({
id: String,
name: String,
documentType: String, // will be used later to pass to different docuemnts
});
const defaultDocumentSchema = basicDocumentSchema.extend({
defaultDocumentField: String,
});
const specialDocumentSchema = basicDocumentSchema.extend({
specialDocumentField: String,
})
try {
if (doc.type === 'default') {
// Keep in mind since you are controlling the schema above you can mutate them however you'd like
defaultDocumentSchema.validate(doc);
Document.insert(doc)
}
} catch (e) {
}
from meteor-collection2.
@harryadel - Quick question about the Schema solution...the line defaultDocumentField.validate(doc)
, shouldn't that be defaultDocumentSchema
instead?
from meteor-collection2.
Ah, yes. it's typo
from meteor-collection2.
Yeah, with the second method, you can create the schema in the method call, adding any dynamic properties before validating
from meteor-collection2.
So, just messed around with the second method validating solely against the schema. It handles errors sent to the client very differently than the first method, which is actually a bit disappointing. It only sends the first error back to the client, rather than looking for all errors in the document.
EDIT: Just saw how to transform the error so Meteor can handle it on the client. Also helps to clean the doc before validating.
Thanks all!
from meteor-collection2.
Related Issues (20)
- [3.0.3] Upsert fails even if document inserted would match the schema definition HOT 2
- Using $pop to remove an array item causes an error HOT 2
- Using the all positional operator $[] in nested arrays causes an error HOT 4
- Upsert no longer works in 3.0.5
- Duplicate key errors not correctly reporting (no Meteor.Error) HOT 3
- Migration from Meteor 1.4 to 1.9, Collection 2 from 2.10 to 3.0, SimpleSchema with meteor-collection2 error on unique option HOT 3
- Can't update the collection HOT 3
- Is it possible to create field type that takes key and value pair? HOT 4
- Writing a robust updatedAt autoValue HOT 4
- CONTRIBUTING.md is missing HOT 1
- Breaking change in v3.2.0 for extending schemas HOT 2
- Delete the name of collections in error messages HOT 5
- Question: A way to log all errors without actually throwing them? HOT 1
- Does not work with `$[]` positional operator HOT 1
- relplace lodash with underscore HOT 3
- FLE-Encryption HOT 3
- Expose defaultCleanOptions HOT 10
- Apply `defaultValue` on `fetch` HOT 6
- Stub exceptions are logged instead of thrown in Meteor Methods, preventing throwStubExceptions from working as intended
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 meteor-collection2.