$new does not produce any $mapping

[ee0pdt]

I am creating a CRUD interface using ModelCore, the save method failed on Create because the $new method does not create the required mapping for the $toObject method. I fixed the problem in my app by copying the mapping from the parent object:

  $scope.posts = new Posts();
  $scope.newPost = $scope.posts.$new();

  $scope.posts.$find().success(function() {
    $scope.newPost.$mapping = $scope.posts.$dataset[0].$mapping;
  });

I'm not sure if there is a better way of doing this?

[klederson]

Hello @ee0pdt ... in order to have the mapping when you use $new you need to pre-map the Model with your structure, otherwise you're going to have errors ( once ModelCore uses the "GET" verb to identify and automatically map the model ).

This line ( https://github.com/klederson/ModelCore/blob/master/src/ModelCore.js#L116 ) explains you that. I used ModelCore.clone() to perform this but not sure if this is going to work in your case.

If you're trying to extract the automatic mapping from a already fetched model you may try an approach like this if that didn't worked ( it supposed to ).

Just to resume: It's impossible to have a mapping in a $new object if you didn't predefined the mapping in the model construction perhaps this be improved somehow but for now that's the approach.

[ee0pdt]

Hello and thank you for the reply. I think my method is the easiest for now because I can get the mapping automatically from my prefetched model. If I predefined the mapping in the construction I will have to update it every time I make changes to the database.

[ee0pdt]

A suggested fix using my method, user MUST have called fetch on the parent model first for this to work...

$new : function(data) {
        var self = this;

        data = typeof data === "undefined" ? self.$mapping : data;

        var o = new new ModelCore.newInstance({},self);
        o._cache = {};
        for(var i in self.$mapping) {
          o._cache[i] = ModelCore.clone(data[i]);
          o[i] = ModelCore.clone(data[i]);
        }

        o.$mapping = self.$dataset[0].$mapping; // clone mapping

        return o;
      },

[klederson]

This if the model already have a dataset or something but this is a wrong assumption. Maybe if we identify if it has a dataset... We must think in all possible scenarios:

1. It has no dataset yet
2. It has dataset but was modified on the fly ( on demand mapping )
3. Relationship mappings (how to deal with it)
4. Issue $pkField should support multimensional fields #7

Let's discuss a while before start coding and "fixing"

[ee0pdt]

Yes. Good thinking. I guess it makes a difference when your schema can change (i.e. in NoSQL databases), but I'm thinking of a MySQL setup where the mapping won't change very often. Issue 7 also makes things more complicated but I can see the need for it (e.g. - Frameworks like Laravel can send pagination data which could be useful if we could map with multidimensional fields... ). The point is that the current code already makes the assumption that there is manual mapping applied for $new objects - assuming that there is a dataset isn't any worse... but I agree that a check should be made first.

[klederson]

Usualy pagination data must come in some format like this:

{
   meta: {....},
   items : {.....}
}

Or... ir done correctly in the header saying that is a partial content x/y for ex...

In the first case your dataset should be items and ModelCore will do that very easyly for you but than your response will be discarted ( the meta part ) once each one implements what needs in it's on way ( i want to provide ModelCore feature to handle pagination using headers and status code as RESTFul specs does says ).

Again we go to the approach:

var pages = {
   next: 0,
   current: 0,
   total : 0,
};
myModel.$incremental({page:pages.next}).success(function(status,response){
   pages.current = response.meta.page;
   pages.next = response.meta.page + 1;
   pages.total = response.meta.totalPages;
});

This is a simple sample and can be improved but as you can see you can work this way... it's kinda hard to abstract all people's mind of how to do that ( names, etc ... ). I had already tough about inset a meta mapping but than a third field would appear and that will look like an ugly workarround.

The way i explained you above, you can do that for example overriding the $incremental or $find method in your own Model and it will be transparent.

[ee0pdt]

Thank you very much for your thoughts on pagination. My original approach had an API that returned:

{
    error: false;
    data: {
        current_page: 1,
        total: 10,
        last_page: 10,
        per_page: 50,
        items: [
              ...
       ]
    }
}

So I have mapped it to the structure you suggest and have a meta array.

I am wondering where you get your specs for the RESTful API? I have looked on the Wikipedia article and they say there is no hard spec for REST as it is an architecture not a protocol...

[klederson]

I did take the idea from V1 but here OData v2 Specs this seem to be a new standard structure.

However what you suggested also follows a second standard inside the same documentation maybe we should do some analysis and implement the meta pattern from the Open Data V2 specs.

[ee0pdt]

Thanks, I'll have a read of the specs and see what I can learn