<div dir="ltr">Ah, that is quite simple then, you actually have to only query a fixed set of mongo collections, and data can be pulled from every girder collection. If your assets are represented by items, you just need to do one query against the item (mongo) collection. If they can also be represented by folders, you'd look up folders as well. Exposing this via a REST endpoint that respects access control policies is also trivial, so this definitely sounds like a good fit for Girder.<div><br></div><div>Thanks,</div><div><br></div><div>-Zach</div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Thu, Jun 29, 2017 at 2:17 PM, Andrés Fortier <span dir="ltr"><<a href="mailto:andres@ekumenlabs.com" target="_blank">andres@ekumenlabs.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks Zach and Jonathan for your replies! To answer Jonathan's question, I was referring to Girder collections and not mongo (sorry for the confusion here, it is unfortunate that the term "collection" is overloaded; I will disambiguate from now on).<div><br></div><div>So, maybe stepping back a little sharing the high-level requirements may be a better approach :). We are trying to build an application to manage assets (xml, png, maybe source code, dlls, etc. An asset can also be composed of many files, so basically an asset can be either a girder file or folder). The application must provide both an administrative back end (we think girder web client would be a fit) and REST API (again, girder REST API seems a fit). We will later on roll out a front end (most likely a Javascript SPA), backed by girder's the REST API. </div><div><br></div><div>Now, the typical workflow we envision is:</div><div><br></div><div>- Someone creates an account and adds assets to the app. Assets have an associated type, which is independent of the file extension or mime-type, so this is configured by the user. The user can then decide to keep the asset private, public or shared with some users / group.<br></div><div>- It should be easy / performant to query all the assets of a given type (plus some variations when it applies, like "all assets of a given type that belong to user X", "all private assets of a given type that belong to user X", etc).</div><div>- It should be easy for a user to download all its contents (e.g. for personal backup).</div><div>- It should support asset versioning (I was going to discuss this in another thread, just mentioning here to give a broad view).</div><div><br></div><div>The approach that we currently have in mind is to have a girder collection per user (so that all the user assets are stored there) and tag the assets with metadata to specify its type (hence the need to query by metadata across different girder collections). Another approach could be to have a folder per user in a single "assets" collection, pretty much like a linux /home directory (which at least would remove the cross-girder-collection query). But again, I'm *very* new to Girder, so it is most likely that I don't know what the best use for girder collections are, so any hints are much appreciated.</div><div><br></div><div>Thanks!</div><div>Andy</div><div><br></div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 29, 2017 at 1:40 PM, Jonathan Beezley <span dir="ltr"><<a href="mailto:jonathan.beezley@kitware.com" target="_blank">jonathan.beezley@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">For clarification, do you mean collections in the sense of mongodb collections, or girder collections? It shouldn't be any problem, for example, searching all items regardless of the parent collection they belong in.</div><div class="m_6789238327681967297HOEnZb"><div class="m_6789238327681967297h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 29, 2017 at 11:27 AM, Zach Mullen <span dir="ltr"><<a href="mailto:zach.mullen@kitware.com" target="_blank">zach.mullen@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">One of the main limitations (or perhaps features?) of mongodb is that a query is applied to only one collection at a time, so your search function would make one query per collection that you wish to search. So, in the case you describe, you'd need to loop over some dynamic set of collections and query each one. Or, create some secondary collection that aggregates all of the data with this metadata field, and contains references to other collections in its documents.<div><br></div><div>Thanks,</div><div><br></div><div>-Zach</div><div><div class="m_6789238327681967297m_6483710594106908546h5"><div class="gmail_extra">
<br><div class="gmail_quote">On Thu, Jun 29, 2017 at 11:22 AM, Andrés Fortier <span dir="ltr"><<a href="mailto:andres@ekumenlabs.com" target="_blank">andres@ekumenlabs.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Zach,<div>thanks for the quick reply. What you say makes as lot of sense, my next question on this was going to be about performance and indexes for this kind of search :). </div><div><br></div><div>Just to clarify, if we go this road, is there a way to query all collections at once or we need to run the query for each collection? I'm asking because we may need to create collections on the fly as the system runs, so it would be great to be able to query all elements regardless of the collection they belong to.</div><div><br></div><div>Thanks again, </div><div>Andy</div></div><div class="m_6789238327681967297m_6483710594106908546m_3551368137405880827HOEnZb"><div class="m_6789238327681967297m_6483710594106908546m_3551368137405880827h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 29, 2017 at 11:48 AM, Zach Mullen <span dir="ltr"><<a href="mailto:zach.mullen@kitware.com" target="_blank">zach.mullen@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Andy,<br><br>Thanks for reaching out! This is actually a common sort of use case, but Girder out-of-the-box does not support it (yet). The main reason for that is because these sorts of queries should typically be performed against a database index so that they can scale up to large numbers of folders/items. So, the recommended route for this case is to create a small plugin that makes sure your desired search field is indexed. To achieve that, you'd add a line like:<br><br><font face="monospace, monospace"> ModelImporter.model('item').en<wbr>sureIndex(['meta.type', {'sparse': True}])</font><br><br>Then, you'd want to probably add a small API endpoint to search by this field, and perhaps even some UI augmentation to expose it somewhere. Let me know if you need help with those other steps.<div><br></div><div>Thanks,<br><br><div>Zach Mullen<br>Kitware, Inc.<br><a href="tel:(919)%20869-8858" value="+19198698858" target="_blank">919-869-8858</a><div><div class="m_6789238327681967297m_6483710594106908546m_3551368137405880827m_1136539944296336620h5"><br><br>On Thu, Jun 29, 2017 at 9:18 AM, Andrés Fortier <<a href="mailto:andres@ekumenlabs.com" target="_blank">andres@ekumenlabs.com</a>> wrote:<br>><br>> Hi all,<br>> first of all, sorry of this is a trivial question, just getting started with Girder. We are currently evaluating using Girder as a backend to store resources (either a folder or a file). One of the requirements we have is that a resource may have 0, 1 or more "types" (although it will most likely be 1 for a starter), which can be plain strings. Also, we want to be able to search resources by type, even if they are in different collections. <br>><br>> Initially we thought on attaching a type property to a resource metadata, which could be an array of strings. However the search bar in the web front-end doesn't seem to support search by metadata, so I was wondering: is metadata search supported on a collection? if yes, how about cross-collection search? If no, should I write a plugin to do that?<br>><br>> Any hints / pointers are much appreciated.<br>><br>> Thanks!<br>> Andy<br>><br></div></div>> ______________________________<wbr>_________________<br>> Girder-users mailing list<br>> <a href="mailto:Girder-users@public.kitware.com" target="_blank">Girder-users@public.kitware.co<wbr>m</a><br>> <a href="http://public.kitware.com/mailman/listinfo/girder-users" target="_blank">http://public.kitware.com/mail<wbr>man/listinfo/girder-users</a><br>><br></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div></div>
<br>______________________________<wbr>_________________<br>
Girder-users mailing list<br>
<a href="mailto:Girder-users@public.kitware.com" target="_blank">Girder-users@public.kitware.co<wbr>m</a><br>
<a href="http://public.kitware.com/mailman/listinfo/girder-users" rel="noreferrer" target="_blank">http://public.kitware.com/mail<wbr>man/listinfo/girder-users</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>