Skip to content
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

upsert does not set ctx.instance #487

Closed
jmls opened this issue Mar 5, 2015 · 3 comments
Closed

upsert does not set ctx.instance #487

jmls opened this issue Mar 5, 2015 · 3 comments
Assignees
Labels

Comments

@jmls
Copy link

jmls commented Mar 5, 2015

using a "PUT" (Update an existing model instance or insert a new one into the data source) where there isn't an existing record, ctx.data is set, not ctx.instance, even if it is a new record

this makes it impossible to perform certain tasks on the creation of a new record using PUT

@superkhau
Copy link
Contributor

Please create a test project on Github to reproduce the issue as per https://github.com/strongloop/loopback/wiki/Issues#bug-report

@fabien
Copy link
Contributor

fabien commented Mar 5, 2015

@jmls which "PUT" are you referring to? I assume you mean PUT /modelName which maps to updateOrCreate.

If your datasource supports updateOrCreate directly, it will be used. In this case there will not be a ctx.instance.

However, if your dataSource does not cater for this optimized scenario, it will perform a find and then performs updateAttributes on the instance. In turn, you will have a ctx.instance in this case.

Finally, if a new instance was created during this step, it will only be available in the 'unoptimized' scenario, just like updateAttributes.

@bajtos bajtos self-assigned this Mar 6, 2015
@bajtos
Copy link
Member

bajtos commented Mar 23, 2015

@jmls the current implementation of updateOrCreate performs a partial update when the record was found, that's why there is ctx.data instead of ctx.instance.

However, if your dataSource does not cater for this optimized scenario, it will perform a find and then performs updateAttributes on the instance. In turn, you will have a ctx.instance in this case.

Let me correct this, you will have ctx.data containing the list of property values to change, and ctx.currentInstance pointing to the model instance being updated.

See the discussion in #482 for more information.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants