-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Transformation.prototype.unserialize | unserialize the row from DB is not working correctly #4079
Comments
Hi @Seafnox! It looks like you may have removed some required elements from the initial comment template, without which I can't verify that this post meets our contribution guidelines. To re-open this issue, please copy the template from here, paste it at the beginning of your initial comment, and follow the instructions in the text. Then post a new comment (e.g. "ok, fixed!") so that I know to go back and check. Sorry to be a hassle, but following these instructions ensures that we can help you in the best way possible and keep the Sails project running smoothly. *If you feel this message is in error, or you want to debate the merits of my existence (sniffle), please contact inquiries@sailsjs.com |
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 inquiries@sailsjs.com |
@Seafnox Thanks for posting, we'll take a look as soon as possible. For help with questions about Sails, click here. If you’re interested in hiring @sailsbot and her minions in Austin, click here. |
I find solution: Instead rewriting exsisting object in Transformation.prototype.unserialize system must create new empty one and unserialize columns from incoming object to created use transformations rules |
waterline/lib/waterline/utils/system/transformer-builder.js
|
Hi @Seafnox -- thanks for this. Do you think you could make a pull request to Waterline that explains this problem in more detail and includes the fix? |
i'll try |
@Seafnox,@sailsbot,@sgress454: Hello, 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 and simply close the issue if possible. On the other hand, if you are still waiting on a patch, please post a comment to keep the thread alive (with any new information you can provide). If no further activity occurs on this thread within the next 3 days, the issue will automatically be closed. Thanks so much for your help! |
@Seafnox,@sailsbot,@sgress454: Hello, 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 and simply close the issue if possible. On the other hand, if you are still waiting on a patch, please post a comment to keep the thread alive (with any new information you can provide). If no further activity occurs on this thread within the next 3 days, the issue will automatically be closed. Thanks so much for your help! |
…'s `columnName` Note that in contrast to the v0.13.x version of this patch, in this case we are _not_ modifying the original record in place. This is for consistency with how it has been working in v0.11.x (see https://github.com/balderdashy/waterline/blob/0.11.x/lib/waterline/core/transformations.js#L154) refs balderdashy/sails#4079
…transforming. Previously, only the last join in the joins array got the `serializeCriteria` treatment, ostensibly because the parent join in a many-to-many didn't need it? But this broke down for queries with multiple populates; only the last of the joins would get transformed. Furthermore, when the joins were being generated, they were already using `columnName` in their `select` clauses, so that when `serializeCriteria` ran it could cause issues if there were conflicts between attribute names and column names (see balderdashy/sails#4079). With this patch, only attribute names are used in the `select` clauses for joins, and then _all_ joins are transformed. Note that in the case of many-to-many joins, the first ("parent") join is expected to have `select: false` and no criteria object. It's not clear why this should be (I think `select: []` and `criteria: {}` should work just as well, and tests pass that way), but to avoid unforeseen issues, backwards-compatibility for that has been added in lines 609-612. refs #1499
@Seafnox,@sailsbot,@sgress454: Hello, 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 and simply close the issue if possible. On the other hand, if you are still waiting on a patch, please post a comment to keep the thread alive (with any new information you can provide). If no further activity occurs on this thread within the next 3 days, the issue will automatically be closed. Thanks so much for your help! |
Sails version: 0.12.11 and 1.0
Node version: 7.4
NPM version: 3.10.9
Operating system: Windows
When model contain some transformations by `columnName` it can raise disapearing columns with values.
If column names from thee DB (Mongo, MySQL, PostgreSQL, etc.) intersect with field names for user like:
then column
ownerId
resieve right value, butidentity
value with column was disappearing:For any cases, when column names are intersect like:
a
->b
b
->c
system can loose one of columns
The text was updated successfully, but these errors were encountered: