Closed heartsentwined closed 10 years ago
Update: so the collation order matters? If I swapped out bar
with car
, now baz_id
will get set properly, but car_id
will become missing.
This should totally work, I'm very surprised it doesn't. Is there any way you could translate this code into a test?
Update: this is actually a regression. git bisect
gives either 6d5cac8 or f2040bd as the first breaking commit. (6d5cac8 errored elsewhere, so I can't pinpoint).
But either of those breaking kinda makes sense, both commits are supposed to be "lazier" / "performance-gain" improvements - now their side-effects come up?
Yeah I am confused as well as to why they have caused this.
ah well, bisect
isn't totally reliable after all; it could be elsewhere
Is this in a child session?
I'm not sure how to write out the test though, I can understand epf
logic pretty much up to the model layer; once the adapter/serializer takes over, I can only resort to "non-standard" debugging. I can write a test case if those console.log()
statements indicate error, but I don't know where to track down the actual missing id
from the request payload.
Re: child session
Makes no difference. The actual use case is in a child session, but I have reproduced this with the main session.
s = App.__container__.lookup('session:main');
I think the test could be pretty high level, just check to see that the id is set in the payload sent down to the server. An example would be here: https://github.com/GroupTalent/epf/blob/master/test/rest/rest.acceptance.em#L55
Thanks for the code sample, I'll put together a test case. What does adapter.r['POST:/users']
do though?
adapter.r
is basically just a hash that can map particular requests to simulated responses (this is a customized adapter just for test purposes). Ultimately, I think I would like to move over to sinon.js for this
ok
@ghempton any update?
Sorry and never mind, turns out it was a 3rd party lib that's breaking epf
, we tried it on a clean ember + epf
environment, and it worked.
EDIT: no, it doesn't work - see comment below
Well that is good, but I still want to get to the bottom of the test failures. I just added an npm shrinkwrap, let me know if that works. Thanks for sticking with it :)
This?
{
"name": "epf",
"version": "0.1.4",
"dependencies": {}
}
That won't lock down any package version at all, you need to do
$ npm install
$ npm shrinkwrap
and the output npm-shrinkwrap.json
will become a giant file containing exact version and info of each dependency.
Oh I should have looked at the output, that is exactly what I did, maybe shrinkwrap doesn't capture dev dependencies?
Yeah, sure enough. Needed the --dev
flag. Just pushed.
still same result. so apparently not related to package versions?
I'm terribly sorry for closing and reopening this, but we made a mistake. This is after all reproducible on a clean ember + epf
- ignore my previous comment, we got tangled in a myriad of libs. So this is still an epf
bug; I'll put together a fiddle.
no worries. I will dig through the fiddle. Also, what version of node are you using?
Edit: a test repo perhaps? coz I need to access (dummy) server API, and I'm not familiar enough with epf fixtures.
I'm on rails, not node
The code is basically the same as above, just demonstrated in a "real time" environment
I was talking about what version of node you are using for the epf tests? I would really like to get to the bottom of your test issue. I think a failing test would be the best way for me to fix this.
v0.8.9
Ah I think that could actually be the problem, I use the latest stable version which is 0.10
I'll try upgrading that
Btw, what do you mean by "demonstrated in a real-time environment"?
well nothing, just like a fiddle, making the code "executable", like you can go to the console and see the error messages for yourself
perfect, upgrading node fixes the test errors
Great, so I wonder what needs to change on the test to make it fail
we now have a test repo, which just contains the code I posted in the beginning. do you still want it?
A failing test would be ideal, but I can take a look at the repo
give us a while and we'll put that on github
over at heartsentwined/epf-test
Only three places worth a look, the rest is boilerplate:
Thanks, I will take a look at this later tonight
Looking over the test code, it seems like FoosController
is not returning the foreign keys for its children? Something like this is what epf expects:
class FoosController < ApplicationController
def create
render json: { foo: { id: 1, client_id: params[:foo][:client_id], baz_id: 1, bar_id: 1 } }, status: 201, location: foos_path
end
def show
end
end
That doesn't matter, because the payload itself is already corrupt.
If you insist, I would make it
class FoosController < ApplicationController
def create
render json: { foo: { id: 1, client_id: params[:foo][:client_id], baz_id: params[:foo][:baz_id], bar_id: params[:foo][:bar_id] } }, status: 201, location: foos_path
end
def show
end
end
so as to reflect the (possibly) missing bar and baz ids.
In any case, the error happens before the foos response; it is the payload sent to this foo end point that is missing the correct baz_id
.
Is this still an issue? Things have changed a lot since this issue was opened. I am going to close for now, please reopen if there are still problems.
Code speaks better than I do -
Basic model, with two
belongsTo
relationships:Test:
Regarding those
client_rev
andrev
attrs. I first observed this behavior when I echoed back only theclient_id
, it seemed from #89 that omitting them will "just work". But it doesn't, so I tried adding them back in, as I thoughtepf
was replacing the models with the server payload. However apparently that isn't the problem - all four permutations (client_rev
andrev
echoed back, or not) produce the same observation.I also tried dropping an empty
foo_ids: []
into thebars
andbazs
responses, but it doesn't help either. Behavior is also the same if I use the mass setterfoo.setProperties({bar: bar, baz: baz})
.Is this an
epf
bug, or am I doing something wrong?