save$ load$ remove$ list$ and.... count$ ?

[akrsmv]

Was thinking whether it is possible to include count$ as a generic action in any entity.. Not sure how this will relate to the idea that seneca-entity should be db agnostic, but I think it would bring a lot of value, since most of the cases a client wants to get a paged list, knowing what are the total items, current page etc. Seneca gurus, is this possible at all :)?

edit: I am coming from the concern that doing list$.length would be very poor in performance

[mihaidma]

@krassi-atanasov seneca has skip$ and limit$ to skip and limit the number of results: https://github.com/senecajs/seneca-store-test/blob/master/store-test.js#L881

Is this what you need? This would be the functionality you need for paging

[mihaidma]

More documentation related to this: https://github.com/senecajs/seneca-standard-query

[akrsmv]

Yup, i red there and am already using skip$ and take$.To give a bit of context: I am building an API with hapi (that is just the endpoints) and seneca (where the domain logic is) - using great transport layer of seneca and the great idea of being db agnostic (to some level). For now "domain" logic is only making CRUD on entities. No specific db yet, just the mem store. I have all the CRUD, plus listing in pages, however - somewhat of a standard for applications is that, rendering paged lists always say something like "showing 21-40" results out of total number itmes.

So my question is how would i get the total items, only using seneca-entities, being db agnostic. At some point I definetley will start to be bound to a particular db plugin. I just wondered if its possible to still stay db agnostic. Or for implementing the total items thing i have to already be coupled with a particular database plugin and go out of being db agnostic?

Also, in one of the documentation pages it is stated that:

Seneca provides a common query format that works across all data stores. The trade-off is that these queries have limited expressiveness (more on this later, including the get-out-of-jail options).

I couldnt find a specific "get-out-of-jail options" section in the documentation so this area is a bit blur for me yet - i.e up to where I can be db agnostic and where is the point I become bound to a specific db implementation? My thoughts were that having seneca-standard-query, we can stay db agnostic for a large set of cases.

But.. here comes the question again - how to provide the simple total items implementation and yet stay db agnostic?

Note that as i said in the above post, using list$.length is not doing the job since you cannot just excerpt huge amount of items from your database, and load them into memory, only to perform count on them :)

[mihaidma]

There is no generic count implemented to all stores. You have to find out the total count using a native query.

[mihaidma]

i'll open a feature request on store-test to add count in the 1.2.0 specifications. Now most stores support 1.0.0 and we are moving to 1.1.0

[akrsmv]

Thanks @mihaidma, spotted the open issue in store-test, closing this one