[Enhancement Request]: Ability to define virtual fields within Simple Schema

[serkandurusoy]

A powerful feature of Collection2 is the ability to define schema structure outside the collection definition.

Coupled with the ability to combine multiple schema structures within Simple Schema, we have a good mechanism for keeping the code dry, abstract and clean.

Virtual fields are a great addition to Collection2. But consider a use case where we have a base schema (e.g. createdAt, createdBy, updatedAt, updatedBy) which we include in all our collections through their respective schemas.

And consider for each document in any collection, I would like to have a virtual field that gives me the email address for the user who has created the document.

In its current form, we need to include such virtual field in every collection or hack it using _.extend etc.

It would be a great feature if one could define virtual field at the schema level as well.

[aldeed]

I understand the use case. Virtual fields are inherently "a collection2 thing" since they rely on transform, but it's possible that we could rethink the options "API" such that they are defined in SS definitions (similar to how denyUpdate, etc. are inherently related to collections, but C2 has you define them in the schema definition object.

Specifically, I'm thinking of something like this:

var c = new Meteor.Collection("c", {
  schema: new SimpleSchema({
    creatorEmail: {
      type: String,
      virtual: function (doc) {
        return getCreatorEmail(doc.createdBy);
      }
    }
  });
});

This would require a way to tell the simple-schema package to ignore definitions that are virtual. I'm not sure I'm sold on doing it yet, but we can keep this open as a proposal.

[serkandurusoy]

You're right, it would also contextually make sense to keep it in c2.

As I am progressing on my first "rather complicated" meteor app (coming
from javaee), I see this multiple times. It may not always be the case
but for the current app, my schemas often share properties that can
otherwise be reused and be represented in other ways. Virtualfields
would have been a great fit for the use case. Currently, I'm trying to
pass those properties through some common utility functions after I
retrieve them. Trying to keep them reactive, though is the harder part
which seems to require even further abstraction. In the end, the code
becomes harder to follow and maintain.

On 01/16/2014 08:07 PM, Eric Dobbertin wrote:

I understand the use case. Virtual fields are inherently "a
collection2 thing" since they rely on transform, but it's possible
that we could rethink the options "API" such that they are defined in
SS definitions (similar to how |denyUpdate|, etc. are inherently
related to collections, but C2 has you define them in the schema
definition object.

Specifically, I'm thinking of something like this:

var c = new Meteor.Collection("c", {
schema: new SimpleSchema({
creatorEmail: {
type: String,
virtual: function (doc) {
return getCreatorEmail(doc.createdBy);
}
}
});
});

This would require a way to tell the simple-schema package to ignore
definitions that are virtual. I'm not sure I'm sold on doing it yet,
but we can keep this open as a proposal.

—
Reply to this email directly or view it on GitHub
#49 (comment).

[serkandurusoy]

Oh, now I get this. Brilliant!

On 01/16/2014 08:07 PM, Eric Dobbertin wrote:

I understand the use case. Virtual fields are inherently "a
collection2 thing" since they rely on transform, but it's possible
that we could rethink the options "API" such that they are defined in
SS definitions (similar to how |denyUpdate|, etc. are inherently
related to collections, but C2 has you define them in the schema
definition object.

Specifically, I'm thinking of something like this:

var c = new Meteor.Collection("c", {
schema: new SimpleSchema({
creatorEmail: {
type: String,
virtual: function (doc) {
return getCreatorEmail(doc.createdBy);
}
}
});
});

This would require a way to tell the simple-schema package to ignore
definitions that are virtual. I'm not sure I'm sold on doing it yet,
but we can keep this open as a proposal.

—
Reply to this email directly or view it on GitHub
#49 (comment).

[aldeed]

@serkandurusoy, after checking out the code for the collection-helpers package, I'm thinking about deprecating virtual field support entirely and having people use that package instead. I think it's a better method. I also opened an issue for a collection-helpers enhancement which, if added, would I think meet your needs.

[serkandurusoy]

Sounds very logical and I'm sure everyone would benefit from the gains introduced by such decision.