Sails: Versioning - /v1/Order and /v2/Order_v2 refer to same sql db table, order.findOne doesnt give good values

Created on 11 Apr 2016  路  13Comments  路  Source: balderdashy/sails

Sails version: 0.12.1
Node version: 4.2.3
NPM version: 2.14.7
Operating system: mac os


I am having an issue with my sails application, i am trying to do versioning in the sails app. For this i have created two models -
/api/models/v1/Order.js
{
attributes:
name,
type
}
/api/models/v2/Order_v2.js
{
attributes:
name
}

Both the above models are referring to same mysql database. DB has all the fields but in model Order_v2 i dont have field type. Everything works fine untile i do Order.find()
Order .find shows only those attributes which are present in Order_v2.

I am not getting any solution to this problem, even there is nothing mentioned about versioning in sails.

Steps to reproduce the issue:

  • create two models with in api/models directory referring to same table in db.
  • try doing model.find
bug resolved

Most helpful comment

Been staring at this issue quite a lot over the last week- but just realized we've been overlooking something important. Could you try setting tableName rather than tablename (i.e. a capital N). The ORM hook in sails takes a default model definition, where the inferred identity is used as the table name, then folds in your app's model definition on top. But if the capitalization of tableName is different, it makes sense there'd be an issue. Case folding in Waterline sees that both tableName AND tablename were provided, and so it uses the preferred capitalization. Arguably, Waterline should error out in this case, but that's neither here nor there. @sapnajindal When you have a moment, would you double check that this fixes the problem?

On a separate note:
After taking another look at this, I started to wonder if it is an issue in the ORM hook. So I looked around and noticed that we are definitely ignoring the explicit identity here. That was one of the bits of code I was unsure about when refactoring the ORM hook, but also didn't want to break backwards compatibility in order to clean up (at least not without doing a new minor version release). While it's unclear from our docs, I would say it most definitely does not _seem_ like the expected behavior. As you can see here, the identity is coming from the module loader, rather than from an explicitly-declared identity on the model definition. Similarly, the model is exposed as sails.models.IMPLICIT_IDENTITY rather than using the explicit identity if one was provided.

Anyway, this is separate from the issue here, since tableName is merged in like everything else, but I wanted to bring it up to take note of it for future reference, or for folks who might run into related problems.

@sapnajindal Thanks for all your help!

All 13 comments

Hi @sapnajindal! It looks like you missed a step or two when you created your issue. Please edit your comment (use the pencil icon at the top-right corner of the comment box) and fix the following:

  • Verify "I am experiencing a concrete technical issue (aka a bug) with Sails (ideas and feature proposals should follow the guide for proposing features and enhancements (http://bit.ly/sails-feature-guide), which involves making a pull request). If you're not 100% certain whether it's a bug or not, that's okay--you may continue. The worst that can happen is that the issue will be closed and we'll point you in the right direction."
  • Verify "I am not asking a question about how to use Sails or about whether or not Sails has a certain feature (please refer to the documentation(http://sailsjs.org), or post on http://stackoverflow.com, our Google Group (http://bit.ly/sails-google-group) or our live chat (https://gitter.im/balderdashy/sails)."
  • Verify "I have already searched for related issues, and found none open (if you found a related _closed_ issue, please link to it in your post)."
  • Verify "My issue title is concise, on-topic and polite ("jst.js being removed from layout.ejs on lift" is good; "templates dont work" or "why is sails dumb" are not so good)."
  • Verify "I have tried all the following (if relevant) and my issue remains:"
  • Verify "I can provide steps to reproduce this issue that others can follow."

As soon as those items are rectified, post a new comment (e.g. “Ok, fixed!”) below and we'll take a look. Thanks!

_If you feel this message is in error, or you want to debate the merits of my existence (sniffle), please contact [email protected]._

Sorry to be a hassle, but it looks like your issue is still missing some required info. Please double-check your initial comment and try again.

_If you feel this message is in error, or you want to debate the merits of my existence (sniffle), please contact [email protected]._

Sorry to be a hassle, but it looks like your issue is still missing some required info. Please double-check your initial comment and try again.

_If you feel this message is in error, or you want to debate the merits of my existence (sniffle), please contact [email protected]._

@sapnajindal by default the unique model identity is derived from the file name. In this case the first order model is getting overridden by the second. If you add an identity field to the model's you should get both loaded. See Waterline-docs for more info.

@particlebanana I have tried giving unique identity also, then also with 'find' , it returns attributes of the new modal only.
My model looks like -

Order.js

attributes: {
....
},
identity: 'order',
tablename: 'orders'

Order_v2.js

attributes:{
....
},
identity: 'order_v2',
tablename:'orders'

Sorry to be a hassle, but it looks like your issue is still missing some required info. Please double-check your initial comment and try again.

_If you feel this message is in error, or you want to debate the merits of my existence (sniffle), please contact [email protected]._

Sorry to be a hassle, but it looks like your issue is still missing some required info. Please double-check your initial comment and try again.

_If you feel this message is in error, or you want to debate the merits of my existence (sniffle), please contact [email protected]._

@sapnajindal sure seems to be an issue. It looks like we are overriding the identities if a tablename is present and I'm not sure why. Digging into this now to see if I can figure out a solution that won't break the adapters.

@particlebanana Sure Thanks!

Been staring at this issue quite a lot over the last week- but just realized we've been overlooking something important. Could you try setting tableName rather than tablename (i.e. a capital N). The ORM hook in sails takes a default model definition, where the inferred identity is used as the table name, then folds in your app's model definition on top. But if the capitalization of tableName is different, it makes sense there'd be an issue. Case folding in Waterline sees that both tableName AND tablename were provided, and so it uses the preferred capitalization. Arguably, Waterline should error out in this case, but that's neither here nor there. @sapnajindal When you have a moment, would you double check that this fixes the problem?

On a separate note:
After taking another look at this, I started to wonder if it is an issue in the ORM hook. So I looked around and noticed that we are definitely ignoring the explicit identity here. That was one of the bits of code I was unsure about when refactoring the ORM hook, but also didn't want to break backwards compatibility in order to clean up (at least not without doing a new minor version release). While it's unclear from our docs, I would say it most definitely does not _seem_ like the expected behavior. As you can see here, the identity is coming from the module loader, rather than from an explicitly-declared identity on the model definition. Similarly, the model is exposed as sails.models.IMPLICIT_IDENTITY rather than using the explicit identity if one was provided.

Anyway, this is separate from the issue here, since tableName is merged in like everything else, but I wanted to bring it up to take note of it for future reference, or for folks who might run into related problems.

@sapnajindal Thanks for all your help!

@particlebanana any luck?

Tested on the latest Waterline (0.13) and the above case works as expected. Didn't see anything that stuck out in waterline-schema as overriding the table name so it might be something in WL 0.11 or in the ORM hook.

@sapnajindal @particlebanana Hi ya'll we are in the process of cleaning Sails issues. It looks like this issue was resolved.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

radoslavpetranov picture radoslavpetranov  路  4Comments

svmn picture svmn  路  4Comments

alxndrsn picture alxndrsn  路  4Comments

Noitidart picture Noitidart  路  4Comments

Sytten picture Sytten  路  4Comments