.find() for the subCollection

[vanerleo]

calling .find() for the subcollection returns the objects of the parent collection:

const companyTable = await database.getCollection('companies');
const table = companyTable.subCollection(`${company.id}-${TABLE_NAME}`);
const documentReferences = await table.find();

documentReferences would contain the files from 'companies'

[vanerleo]

the issue i think is in AWSProvider : 124

  if(fqn.name.indexOf('/')!==-1) params.Delimiter = '/';
        if(startsWith) params.Prefix = fqn.name.indexOf('/')===-1 ? startsWith : `{fqn.name.substring(fqn.name.indexOf('/')+1}/${startsWith}`;

[keithburrows]

Adding to this issue, it would be useful if subCollections were cached in some way. I am not sure of your initial thoughts behind them, but from my perspective it would be great if they could inherit as much of a collection functionality as possible

[matt-filion]

Are you both still using subCollections? I never really put a ton of effort into this as there only seemed to be a couple cases. 3.X was released just now so want to gauge if this is something i should address in the new version.

[vanerleo]

yes, sub collections are useful

[matt-filion]

How do you use them? Are you iterating through a lot of records, or doing CRUD operations on an item within the collection?

I'm thinking about updating the way that find works to use the iterator pattern so you can keep going without having to use a continuation token.

[vanerleo]

Storing related data for parent entity under that entity, IE : CompanyID => Users
this way clean up and reporting is "self contained"

[keithburrows]

I am using them for monitoring a (work)flow of lambdas run (as I go tired of the dynamodb restrictions).
Each lambda run instance currently is a sub collection.
Looking at the new documentation and what you have commented, I think that subCollections do not exist in v3 at the moment?

[matt-filion]

Not yet. Should be there this week ish. Just want to be sure that I consider this feature properly. I built it without use case of my own.

…

On Sun, Mar 31, 2019, 3:56 PM keithburrows ***@***.***> wrote: I am using them for monitoring a (work)flow of lambdas run (as I go tired of the dynamodb restrictions). Each lambda run instance currently is a sub collection. Looking at the new documentation and what you have commented, I think that subCollections do not exist in v3 at the moment? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#27 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUplBBk97-jOB15gif0z6NDxVypXDG1ks5vcT01gaJpZM4VhZbr> .

[matt-filion]

Alright, I've got a branch for this.

https://github.com/matt-filion/s3-db/tree/3.0.3_child_collections

PR if you feel like reviewing. #38

Should work more or less the way it did before. I've removed any knowledge of delimiters and left it up to the caller to provide the prefix exactly as desired.

From the docs

---

subCollection(prefix): Collection

Creates a new collection where all operations will execute with the prefix in front of the id's used. So if the prefix is /users/ then when .load('1234') is called the request will result in an ID lookup for /users/1234. Similarly, all objects saved will have the prefix applied when the ID is generated by the save operation, or, when an ID is provided and it does not startWith() the configured prefix.

[matt-filion]

Any thoughts on this ^^

[vanerleo]

thats what i'd be expecting
will try to test it soon

[matt-filion]

KK. Only change i need to make is increase the version properly to 3.1.0 instead of 3.0.3 but otherwise I think it seems good to go.

[keithburrows]

Sorry, I am not going to get to this for a short while as I don't think I currently have time to upgrade to 3.n.
Thanks for all the effort though as I definitely will in the next couple of weeks.

[matt-filion]

Bump on ^^. Want to put some effort towards this project over the weekend and be nice to have this to roll into mainline.