-
-
Notifications
You must be signed in to change notification settings - Fork 17
Make use of dburles:mongo-collection-instances #28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Note: I added a feature request to the files package where the FilesCollection would be references by the Mongo.Collection: veliovgroup/Meteor-Files#464 If that feature would be accepted and added, the line
would not be required to be added manually. |
} | ||
|
||
this.collection = Meteor.connection._mongo_livedata_collections[this.data.atts.collection]; | ||
console.log(this.data); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sry for this, removed all others but that :-/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can remove it by additional commit, no need to send PR, it will go to this PR
} | ||
|
||
this.collection = Meteor.connection._mongo_livedata_collections[this.data.atts.collection]; | ||
console.log(this.data); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can remove it by additional commit, no need to send PR, it will go to this PR
- Support for `dburles:mongo-collection-instances`, see #28 , thanks to @jankapunkt - `dburles:mongo-collection-instances` is possible fix for issues like #19
@jankapunkt thank you a lot for contribution. Published as |
I don't intend to use global namespace, since all my collections are encapsulated and referenced via dburles:mongo-collection-instances.
However, I also do not like workarounds in onRendered template functions. This approach assumes the convention of linking your FilesCollection to it's underlying collection instance.
Example:
Link the FilesCollection instance to the Mongo.Collection instance:
Retrieve the FilesCollection as every other collection instance:
The change does not add a dependency to dburles:mongo-collection-instances but only checks if it's functionality (Mongo.Collection.get) exists. If not it falls back to the old mechanism.