Is this ready for Ember 1.0?
kevinseelbach opened this issue · comments
I ran the tests with latest version of Ember, Handlebars, and the Ember-states plugin, and all passed with 0.13 ember-data.
If I stick with the older 0.13 version of ember-data, should I be good to start developing with the release versions of the other Ember files?
Is there a plan to update when Ember-data 1.0 is released?
Yes, I plan to update the adapter with Ember-1.0 and Ember-Data-Beta-1. I should have it ready at some point this week.
After doing some frustrating work, I realized that hasMany relationships are still not working in ember-data-rc2 http://discuss.emberjs.com/t/ember-data-1-0-0-beta-code-snippets-on-how-to-use-a-hasmany-relationship/2587
I think it will be better if the adapter does not get updated to 1.0 until is finally released.
Did you find any issues using Ember 1.0 and Ember Data 0.13?
Sadly, I stuck with Backbone for now. I'm building a prototype for a startup idea and am a bit afraid to dive into Ember without knowing how to make it all work... Backbone seemed easier to customize but I'm looking forward to investigating Ember further when it's more stable since I think it will help with view management and boilerplate.
I, too, would like to know when Ember 1.0 support is ready. Let me know if you need specific help with anything.
So, I've spent a good chunk of this evening trying to get this adapter working with Ember 1.0. Here's what I've learned:
-
This adapter is not compatible with Ember Data 1.0-beta-2. At least not for me. I couldn't get anything to work correctly. And it also looks like the relations are busted at the moment so you're better using the version this adapter was tested against: Ember-Data 0.13.
-
I couldn't get this adapter to install with bower 1.2.6. Specifically it failed trying to download Ember Data (See the bower.json: bower.json#L6). I ended up doing this:
- Download the Ember Data 0.13 zip directly:
bower install https://github.com/emberjs/data/archive/v0.13.zip - Manually download the @escalant3's django-tastypie adapters
- => And as a gotcha, bower defaults to Ember 1.0.0-rc.6 so you'll need to specify master for Ember 1.0.
- Download the Ember Data 0.13 zip directly:
-
IMPORTANT The Ember team moved some of the code from Ember Data into emberjs/ember-states so you'll need this in order to play well with Ember Data 0.13 and this adapter. It's also not complied so you'll need to build from source. As long as you have Ruby installed, it's as simple as
bundle && rake dist -
Instead of creating the store with
.create(), use.extend(). Otherwise, you'll receive an error in tastypie_adapter.js for trying to extend a DS.RESTAdapter that doesn't exist. E.g.,App.store = DS.Store.extend({ adapter: DS.DjangoTastypieAdapter.extend() });For more on this see emberjs/ember.js#2988
I think that's about it. I got a basic working version of an ember app pulling from a fairly robust Django Tastypie API. I haven't done anything too complicated yet, but hopefully this all helps folks out trying to use the latest version of Ember with this Adapter. Happy coding!
Hey guys,
I did an Ember Data 1.0 beta 3 compatible adapter. Any any ideas/issues are welcome
Nice @ddemid
My main issue is that I don't find a way to create unit tests for the adapter with the last Ember versions. I wish Ember was as easy to test as other frameworks.
Maybe I should just code it and temporally forget about the tests.
I've updated the build system and all the tests (it's not passing all tests, some might be wrong, but it's a start!), renamed a few things (to reflect better what ember-data is using), and merged @ddemid code to my clone: https://github.com/pedrokiefer/ember-data-tastypie-adapter/tree/ember-data-1.0-beta
I'm using ember-dev for the build system, and the tests have the same structure as ember-data.
It's still a work-in-progress, most of my commits doesn't make any sense (I'm just pushing to github so I can work from another machine.).
@escalant3, @ddemid
All tests pass now, and I've implemented support for extracting embedded hasMany and belongsTo objects.
thanks @pedrokiefer @ddemid and @escalant3
@pedrokiefer Really good job ;) Is there something new about embedded records without IDs ?
@pedrokiefer Awesome, I'll have to check this out when I get a chance!—
Sent from Mailbox for iPhone
On Thu, Nov 28, 2013 at 12:02 PM, Thomas Durin notifications@github.com
wrote:
@pedrokiefer Really good job ;) Is there something new about embedded records without IDs ?
Reply to this email directly or view it on GitHub:
#27 (comment)
@pedrokiefer I just had a look at your branch. Lots of changes there. Thank you so much :)
Although I haven't worked with Django and Ember in a while I really want to get this updated. Please give me some time to go through the commits and try to understand the inner changes for the new version.
- Could we squash the commits somehow so we have a smaller number of them? There are several experiments that we don't need to add to the repo.
- This change pedrokiefer@d5a1fdd affects almost everything. It even changed the package name.
- I'm not familiar with ember-dev. I need to catch up with that
Maybe we can work together to create a PR.
@pedrokiefer everything looks fine. I needed to upgrade my Ruby that I never use but all the tests pass. Can you please put together a PR?
PS. Are you currently using it on production?
@escalant3 I didn't deploy it yet. I'm still fixing the rest of the app to be compatible with ember 1.1 and ember-data 1.0.
I've changed the package name so it would be more inline with ember-data adapters. The huge changes were kind of necessary for using ember-dev.
Ember-dev has one issue, that on its test template it doesn't include a remote / embedded ember-data.js. So I've added a beta version to /dist, which I think is wrong. I'll open a issue / submit a PR there to fix this.
I don't think I'll be able to work on it this weekend, but my plan is to squash commits and add relevant commit messages. Then I'll do a PR.
@pedrokiefer @ddemid I hadn't read this comment thread as far as I should have before opening issue #28,
I like the embedded loading record support in @pedrokiefer's version, obviously neither has side-loading or embedded record creation support. I'll fork yours for now, but how soon do you think you'll merge it into the main branch?
@jthoburn I expect to work again with Ember Data after the holiday season. If we cannot merge @pedrokiefer changes I will upgrade this repo to support 1.0.
You mentioned you were planning to have side-loading. How are you using tastypie to do so?
Our backend guys are handling that, not me, so I don't know a ton of the specifics but I believe we're using hydration and bundles to add in additional records where needed for hasMany. Our implementation should firm up by January 5th or so, I'll drop specifics on how we did it then what the resulting output looks like then. See: http://stackoverflow.com/questions/11230607/how-to-combine-mutiple-resources-in-django-tastypie
I have a working solution on another adapter for creating embedded records (e.g. new client has new contactInfo which also has new Address). There's probably a better method, but here's a gist of how I've been doing so: https://gist.github.com/jthoburn/8116167
quick update
I've made pretty good progress on a version being used on our dev servers: I ended up using parts of the original RESTAdapter, a few things from @pedrokiefer (his version turned out to be largely broken), and a few from @ddemid (worked, but only for very basic tastypie setups).
One of the things I've found is that embedded records will cause django-tastypie to throw errors when the schemas aren't properly aligned, so I'm adding in a schema check for each record / embedded record being returned to ensure that the fields are set correctly.
I have created a branch[1] with my progress upgrading the adapter. I am targeting Ember 1.3.1 and Ember-Data 1.0-b5.
I've taken a lot of stuff from @pedrokiefer's fork to have experimental embedded records support. I still have to rewrite the whole test suite but I am pushing the changes in case anyone wants to try/improve it.
I've tried successfully all the CRUD operations. Embedded support needs to be tested, although I was able to load data using the standard full=True tastypie option. Sadly, I am not working in any Ember/Django project right now, so it's difficult for me to fully test the adapter. I am using so far my dummy demo app[2].
I'll try to have everything pushed to master this week.
Thanks to everyone for your collaboration and specially to @pedrokiefer for his awesome fork. I want to switch to an Ember gig in 2014 so hopefully I will be updating more frequently.
[1] https://github.com/escalant3/ember-data-tastypie-adapter/tree/1.0-b5
[2] https://github.com/escalant3/django-ember-example
The beta 5 is crucial, it fixed async=true on records. I've run into a lot of interesting issues and I'm trying to figure out if they are unique to our django-tastypie setup or are something I need to find a way to address in a larger manner.
The first issue is mis-aligned attributes: Ember-Data's need for two way binding on relationships for proper lookup results in relationship data being sent back that django-tastypie might not be expecting. To handle this I cache the attributes that django knows about and filter/log our relationships on ember models that aren't known about by django (but does not filter mis-aligned attributes that aren't relationships, which also occasionally happens, as these should be allowed to error).
The other issue is how tastypie handles PUT/POST truthiness with relationships. If I send django a request in which the relationship data is only partial (e.g. not all of a hasMany had been made known yet / someone else had added another related object in the meantime) it currently results in django-tastypie removing the missing relationships. As far as I can tell, there isn't a tastypie setting to govern this behavior. Has anyone else encountered it, and how have you handled it?
We're constrained to Chrome, so for us using PATCH instead of PUT and filtering to only changed attributes is an option for non POST requests.
In closing, I'm disappointed that transactions haven't been returned to ED as quickly as has been suggested by Yehuda, mostly because in our setup we have a lot of related models that get created together. The ability to use bulkCommit=true and implement createRecords and updateRecords via PATCH would be awesome.
I merged all the progress into master. I'll close this issue as we should be able to work with ember-data 1.0-beta5 now.