camelCase vs lowercase Services and Models on the Sails global object

[randallmeeker]

In the global name space Models and Services will retain their cameCase name. On the sails object they are lower case.

Bug?? Or No Bug?

[tjwebb]

Not a bug, but maybe not well documented. The whole model name on the sails.models namespace is flattened.

[brandonsimpson]

I noticed this yesterday as well when trying to re-order response objects the way they're defined in the model attributes after they come back jumbled after doing a find().populate(). A different issue that, but accessing the sails model attributes is all lowercase.

If anyone is interested in knowing now to reference the attributes defined in a model, it can be referenced like this:

var modelAttributes = Object.keys(sails.models.products._attributes);

[tjwebb]

var modelAttributes = Object.keys(sails.models.products._attributes);

Simply sails.models.products.attributes will also work, as one might expect. _attributes is used internally by sails and waterline.

re-order response objects the way they're defined in the model attributes after they come back jumbled

I'm not sure what "jumbling" you're referring to, since there's no such thing as the "order" of keys in JSON: RFC-4627

An object is an unordered collection of zero or more name/value
pairs, where a name is a string and a value is a string, number,
boolean, null, object, or array.

[brandonsimpson]

Strange... for what I'm doing ._attributes works fine but .attributes doesn't work when the model has an attribute that is a function, such as a toJSON: function() {...}. I get an error TypeError: undefined is not a function at Object.module.exports.attributes.toJSON. Not sure if this is a bug or what, and I can open another issue if needed.

As for the "jumbling" of data, basically I'm using just the keys of the model attributes to map the JSON response how I expect it to be formatted based on the order of the schema and model definitions. I understand objects can't be "sorted" but I also don't want all of the populated associated data to always come first in the response object. If anything, I'd be happy if it came last because it can be large arrays of associated data. It doesn't matter from a code standpoint to reference the object wherever the data is placed, but it is rather annoying to look at while developing, debugging and documenting your JSON responses when your main data is pushed below your associated data. Anyway, it's kind of a hack but this works to return the results in the order that I've already defined in my schema and attributes and have come to expect my results to look like. This could also just be a waterline issue.

Here's a simplified version of what I'm doing...

var modelAttributes = Object.keys(sails.models.products._attributes);

// ...Model.find().populate()...

var response = _.chain(results.products)
            // ...other maps, filters, etc removed for example
            .map(function(p) {
                // return results objects in order of model attributes
                return _.object(_.map(modelAttributes, function(n) {
                    return [n, p[n]];
                }));
            })
            .value();

        return res.ok(response);

"jumbled" result object from normal find().populate()... notice the categories and variants arrays are pushed to the top, these are populated associations.

{
    "categories": [],
    "variants": [],
    "store": 5,
    "supplier": null,
    "_id": 1,
    "sku": "12345xxx",
    "name": "Test Product 1",
    "description": null,
    "kit": false,
    "createdby_user_id": 33,
    "remote_product_id": "",
    "availability_id": 0,
    "remote_skus": null,
    "barcodes": null,
    "state": 0,
    "production_days": null,
    "box_count": 0,
    "re_order_level": 0,
    "min_unit_order": 0,
    "unit_cost": 0,
    "box_price": 0,
    "sale_price": 0,
    "list_price": 0,
    "kit_price": 0,
    "storage_code": "",
    "active": true,
    "createdAt": "2015-02-09T17:41:34.000Z",
    "updatedAt": "2015-02-09T17:41:34.000Z"
  }

"sorted" result object the way the model is defined, categories and variants are towards the bottom where they belong

{
    "_id": 1,
    "store": 5,
    "sku": "12345xxx",
    "name": "Test Product 1",
    "description": null,
    "kit": false,
    "createdby_user_id": 33,
    "supplier": null,
    "remote_product_id": "",
    "availability_id": 0,
    "remote_skus": null,
    "barcodes": null,
    "state": 0,
    "production_days": null,
    "box_count": 0,
    "re_order_level": 0,
    "min_unit_order": 0,
    "unit_cost": 0,
    "box_price": 0,
    "sale_price": 0,
    "list_price": 0,
    "kit_price": 0,
    "storage_code": "",
    "categories": [],
    "variants": [],
    "active": true,
    "createdAt": "2015-02-09T17:41:34.000Z",
    "updatedAt": "2015-02-09T17:41:34.000Z"
  }

[tjwebb]

Strange; would you mind opening a new issue for that?

[CWyrtzen]

What's the update here? Is there a new issue? Can we close this up?

[sailsbot]

Thanks for posting, @randallmeeker. I'm a repo bot-- nice to meet you!

It has been 30 days since there have been any updates or new comments on this page. If this issue has been resolved, feel free to disregard the rest of this message. On the other hand, if you are still waiting on a patch, please:

• review our contribution guide to make sure this submission meets our criteria (only verified bugs with documented features, please; no questions, commentary, or bug reports about undocumented features or unofficial plugins)
• create a new issue with the latest information, including updated version details with error messages, failing tests, and a link back to the original issue. This allows GitHub to automatically create a back-reference for future visitors arriving from search engines.

Thanks so much for your help!