Meteor-files: Is it possible to have two file collections?

[todaysnewidea]

Apologies in advance for what is likely to be a daft question and that I have missed something obvious but is it possible to have two file collections in a single Meteor app?

I am running Meteor 1.6.0.1 and ostrio:files 1.9.6 on a MacOs X High Sierra development machine.
I followed the sample code and documentation and got things working very nicely for a collection I called teaserImage and to keep things organised I thought I would create a second file collection called contentImage. All I did was duplicate the working files then change the name of the collection in the duplicated files and then add the relevant import commands.

What seems to happen is that the teaserImage collection all works as before so no change there. Uploading to the new contentImage collection all woks as expected in that I can see the entry in the mongo collection and I can use the contentImage.link(image) method to retrieve the public url. However, whenever I try to fetch that url I get the response "File Not Found :(" in the browser despite the url format being the same as for the teaserImage collection and the fact that I have verified the existence of the actual file in the storage path.

Manually editing the code files that handle the contentImage collection so that they refer to the teaserImage collection instead, for test purposes, confirms that the supporting code works as expected. So to me it seems that there is an issue with this second file collection.

Hence my question .... is it possible to have two file collections?

[mksh-su]

Hello @todaysnewidea ,

Yes, it is possilble to have two file collections. You may follow this link to see the example of using two collections.
Please, give us the code where you use two collections so we could tell what is the problem. Thank you!

[todaysnewidea]

Thanks for the very fast response! I thought that multiple files collections must be possible and that I must be doing something silly... I will follow through the link you gave me but in the meantime have attached some files that I hope make my mistake glaringly obvious to someone that knows what they are doing :-)

There are 5 files attached:

1. "MongoDB file collections extract.txt" this shows the data for a file contained in each collection
2. "teaserImage.js" this is the definition of the teaserImage collection
3. "contentImage.js" this is the analogue of the above for the contentImage collection
4. "manageimages.js" this is the code I am working on to maintain a list of content images
5. "manageimages_teaser.js" this is the same code as above but with all relevant lines changed to reference the teaserImage collection instead of the contentImage collection

Item 5 produces a list of images as expected whereas item 4 results in "File Not Found" for each image in the contentImage collection. For test purposes, to rule things out, I have deliberately chosen the same storage path and downloadRoute for both collections.

Looking at the urls for a working teaser image vs a non working contentImage I can't see the issue

Working url:http://localhost:3000/images/teasers/CepjMunzvqYAzeN24.png
File not found url: http://localhost:3000/images/teasers/3dzbe5AcYe9Xz5CXz.png

MongoDB file collections extract.txt

teaserimage.js.txt
contentimage.js.txt
manageimages.js.txt
manageimages_teaser.js.txt

[mksh-su]

Hello @todaysnewidea ,

Please, share your files using gist.github.com so we would be sure that they are safe to open.
Answering your question - please, read our FAQ.

[dr-dimitru]

@todaysnewidea I belive you've run into the issue described in our FAQ:

Note: __All files will be removed as soon as your application rebuilds__ or you run meteor reset.

@mksh-su reference and a cite are necessary here

[todaysnewidea]

@dr-dimitru thanks for the suggestion regarding the storage path. I was aware of this having read through the FAQ when I first started using this and have just checked again that my storage path is outside the meteor folder. Also the fact that both my teaserImage collection, which works, and the contentImage collection, which does not work, utilise the same storage path at present would tend to suggest this is not a factor.
I will upload my files to gist.github.com as @mksh-su has requested and follow through the sample code in the link he provided in the hope of spotting something I have missed. I will also tweak a copy of that code to make it a bit more like my own code e.g. two image collections common storage path etc.
To me it almost seems that instead of trying to find the file in the contentImage collection when the url is referenced in a browser the code tries to find it in the teaserImage collection which results in a file not found.

Thanks again for all the support so far

[todaysnewidea]

I hope I have created the gist the way you guys wanted it :-)

https://gist.github.com/todaysnewidea/81c45d47f91948e1b40a6e0ebcbb5df3

[dr-dimitru]

Hello @todaysnewidea ,

I suggest to omit public option for right now.

public option must be sed only when you're planning to serve files with Nginx, Varnish, Apache or any other proxy server. From the docs:

• Collection can not be public and protected at the same time!
• downloadRoute must be explicitly provided. And pointed to root of web/proxy-server, like /uploads/
• storagePath must point to absolute root path of web/proxy-server, like /var/www/myapp/public/uploads/

[dr-dimitru]

And one more important note:
__downloadRoute must be different for different collections!__ This rule applies to both public and classic collections.

[todaysnewidea]

@dr-dimitru thanks for all your input ....

Given your help I have my code working as expected. The key issue seems to be that both the storage path and the downloadRoute has to be unique. Changing the public state made no difference.

Looking back at my code changes I think I had made things more convoluted than they were as I had encountered the link issue that existed just prior to version 1.9.6 and in an attempt to understand that issue had "simplified" my file structure. In hind sight I think I essentially broke it instead of simplifying it by moving to a single storagePath/downloadRoute.

Many thanks again for your help and the excellent work you guys have done

[dr-dimitru]

@todaysnewidea

Thank you for feedback. I'm glad you've fixed this issue.
Could you tell me more on your plans about public flag:

1. Why you've decided to use it?
2. With what proxy-server it will be used?
3. Is the documentation clear enough about its usage?

[todaysnewidea]

My thinking was primarily performance and caching related ...

1. The documentation says NodeJS is not the best at serving files and I wanted to minimise database hits also it seemed logical to let the web server do the work it was designed to do
2. Proxy server is NGINX configured with Phusion Passenger and prerender.io
3. I think the documentation on the public flag is clear enough but downloadRoute and storagePath could do with a little clarification. For example I initially considered the download route to be just an alias path and not actually crucial

[dr-dimitru]

@todaysnewidea Thank you for feedback on this.

1. Right, usage depends on use-case;
2. Great choice 👍 ;
3. Suggestions to definition of downloadRoute and storagePath are highly welcome. Also you can contribute with a PR, wiki source is here.