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:
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:
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.
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
tableNamerather thantablename(i.e. a capitalN). 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 oftableNameis different, it makes sense there'd be an issue. Case folding in Waterline sees that bothtableNameANDtablenamewere 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
identityis coming from the module loader, rather than from an explicitly-declaredidentityon the model definition. Similarly, the model is exposed assails.models.IMPLICIT_IDENTITYrather 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!