Maybe add the ability to give names to the local collections?

[ivansglazunov]

abc = new Mongo.Collection(null, { localName: 'abc' });
Mongo.Collection.getLocal('abc'); // 1
Mongo.Collection.get(null, { localName: 'abc' }); // 2
Mongo.Collection.get('abc'); // 3

Perhaps it would be necessary to add this capability. I doubt in the interface. Which of these options is more like it? How the best option to name? localName somehow ugly.

[ivansglazunov]

I have the package shuttler:ref where it would be very useful.

[dburles]

Yeah that's a bit tricky, I'm not entirely sure of the potential use cases (we haven't had any issues crop up relating to looking up null collections so far)

[ivansglazunov]

so far I have 2 options:

• I will make a package ivansglazunov:mongo-collection-instances-null as wrapper with 3 option and name field.
• I will make pull request if you approve option

[dburles]

Potentially we could allow extra naming feature for both null and named collections, this may make handling multiple connections a lot more intuitive

[dburles]

Rather than passing in the connection, we can instead reference the name

[ivansglazunov]

If you specified an alternate name in the options, the main will be used?

[dburles]

Foo1 = new Mongo.Collection('foo', { ref: 'foo1' });
Foo2 = new Mongo.Collection('foo', { ref: 'foo2', connection: ... });

// if a 'ref' is passed in, we use that name rather than 'foo'
Mongo.Collection.get('foo1');
Mongo.Collection.get('foo2');

[dburles]

I think in that case, if you define null collections without a reference, we just ignore them

[ivansglazunov]

Mongo.Collection.get('foo'); // too ?

[ivansglazunov]

Should not be ignored. For example, we use custom adapter instead of DDP.

[dburles]

I don't think that'd be possible due to the name clash

[dburles]

Do you mean another connection?

[ivansglazunov]

Yes.

new Mongo.Collection(null, { connection: ourCustomDB });
Mongo.Collection.get(null, { connection: ourCustomDB });

[dburles]

In that case you would also provide a ref on instantiation just like above. Will that not work in your case?

[ivansglazunov]

Yes, it was cool. Only then it is not clear for what we need the second argument of the get

[dburles]

Hmm, can you confirm that arbitrary options make it through to addExtension?

[dburles]

I think it should be alright, you will specify the ref option for null collections, as well as any collections that are on a different connection. Perhaps Mongo.Collection.getRef('...') is better?

[dburles]

That will solve this outstanding issue: https://github.com/dburles/mongo-collection-instances/issues/22

[ivansglazunov]

get => getAll getRef... Not very much. I liked the .get(name/ref: String)

[dburles]

Though it would be possible to overwrite a ref if we later define a collection with the same name which may be confusing?. The advantage of using getRefmeans the two are distinct.

[ivansglazunov]

It is a question of validation and comparison of patterns. Name conflicts can not escape. If the owner of the application knows which makes, then it is a true owner of the app :)

[ivansglazunov]

Exit - namespace tree :) And I think this is not the exit.

[dburles]

Let's go with just get, happy for you to continue with the PR along with some tests for the new functionality

[ivansglazunov]

I think for backward compatibility should leave collection.

[dburles]

I agree, though it's not entirely working, see here: https://github.com/dburles/mongo-collection-instances/issues/22

[ivansglazunov]

May be because connection must be an object with _lastSessionId field?

[dburles]

Possibly. Let's continue discussion on the PR.