Open kpala opened 6 years ago
Thanks @kpala - I haven't had a chance to look into this yet. Any ideas @coagmano?
@kpala which FilesCollection are you using?
I was under the impression that collections with a null connection didn't call _callMutatorMethod
because they don't have a connection. In a standard Collection, all calls to that function are wrapped in an if (this._isRemoteCollection()) {
block here, here and here
The only other call to throwIfSelectorIsNotValid
is in _defineMutationMethods
here, which shouldn't run because it's wrapped in an if
block that checks the truthyness of the connection here
@hwillson Correct me if I'm wrong about allow/deny rules not being called for null/local collections on the client
I suspect the FileCollection is setting a connection in it's constructor, and we use that constructor to build the local collection to preserve custom behaviour. Any other ideas?
So I went for a google for FileCollections and found that most implementations are not compatible with
File-Collection: vsivsi:file-collection
Doesn't pass through the options in the constructor. Also adds a string to the name, so it wouldn't actually stub the collection.
CollectionFS: cfs:standard-packages
Doesn't pass through options in constructor. Also adds a string to the name, so it wouldn't actually stub the collection.
Meteor Files: ostrio:files
Would need to stub FilesCollection.collection
instead of FilesCollection
directly. Otherwise should be okay
We could test if the name or connection is not null after initialising localCollection, and issue a warning that an actually local collection could not be created?
In this project I used vsivsi:file-collection
.
Sorry should have noticed earlier that according to the logs it's indeed related to the FileCollection.
In that case, it's likely that StubCollections
was never actually stubbing the FileCollection in older versions
@hwillson What are your thoughts on how StubCollections
should handle the case where an extended collection doesn't behave in a way that we can force it to use a LocalCollection?
If dealing with constructors like this is too hard, we could resolve the error by providing a method so the client can ask the server to remove from the collection (ie. how xolvio:cleaner does it on the client) on restore.
Hi
After upgrading from 1.0.7 to 1.0.8, I get the following error when running
restore
on a client side collection:I guess this is caused by
localCollection.remove({});
(https://github.com/hwillson/meteor-stub-collections/blob/master/index.js#L35) which tries to clear the collection without providing identifiers.