openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodric Rabbah <rod...@gmail.com>
Subject Re: Use an explicit property to define type of Whisk entity
Date Fri, 08 Dec 2017 04:19:04 GMT
Adding an entity type can work - it would simplify the views. It's mostly a
historical footnote why it doesn't exist and why it's inferred.
You'll have to augment the serialize entity type to add this property (but
I would not add it to the actual types since it's redundant).
This could benefit the unmarshalling that happens when reading entities
from the data store. Brendan McAdams might also have some thoughts on this.
The same applies for the rootns: it's a space/time tradeoff why it doesn't
exist: it's cheap to recompute in the view vs the space the redundant
information would occup.

I've previously explored consolidating the views as you suggest. One reason
not to do that is that the different entity types change at different rates
- by having different views for each type, it is potentially cheaper to
recompute some views.

Changing views requires recomputing the indexes in live dbs before roll out
- to this effect, we've recently added versioned views which allows
deploying new views before they become active. So it's important to add a
feature toggle in the code that's specific to the view versions.

-r




On Mon, Dec 4, 2017 at 6:11 AM, Chetan Mehrotra <chetan.mehrotra@gmail.com>
wrote:

> Hi everyone,
>
> Currently all whisk entities are stored in "whisks" collection in
> couchdb. Most queries around these entities are of form [root
> namespace, date] invoked against entity specific views.
>
> GET /local_whisks/_design/whisks.v2/_view/packages?descending=
> true&endkey=["guest",0]&reduce=false&startkey=["guest","￰","￰"]&limit=30
> 200
>
> The views are computed by "inferring" the entity type [1] based on
> document properties.This mode of querying works fine with couchdb
> which provides "computed" views. However it poses problem with storage
> system where query relies on declarative indexes.
>
> Proposal
> ------------
> Introduce 2 properties
>
> 1. 'entityType' - whose value is set to action/package/rile/trigger
> etc at time of creation.
> 2. 'rootns' - Root namespace
>
> These properties would be set at time of creation itself in
> Controller. This would allow creating a declarative index for the
> entities. For e.g. in Mongo terms we can have a single index
>
> db.whisks.createIndex({entityType:1, rootns:1, updated:1}
>
> This may also possibly allow us to have a single view in couchdb whose
> structure would be
>
> [entityType, rootns, date] = { .... } //docs properties would be
> superset of properties included in views for
> action/package/rile/trigger
>
> Thoughts?
>
> Chetan Mehrotra
>
> [1]
> var isPackage = function (doc) {
>         return (doc.binding !== undefined)
>  };
> var isAction = function (doc) {
>      return (doc.exec !== undefined)
>  };
>  var isTrigger = function (doc) {
>         return (doc.exec === undefined && doc.binding === undefined &&
> doc.parameters !== undefined)
>  };
>  var isRule = function (doc) {
>         return (doc.trigger !== undefined)
>  };
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message