Open jarredwitt opened 11 years ago
Thank you for moving the issue from ember-model to here. First thing first - Will you be my mentor for this project? I come from C++ and RDBMS world, so embedding is little scare for me. More over my data model is complex. If you see my models project - hasMany - sprint - hasMany - stories - hasMany - task (future: - hasMany - TimeSheet). Then project also -hasMany - teamMember, backlog. Each entity project,sprint... will have comments, attachment sections.
I also found a work around for the issue. project_id: Ember.attr(), // project: Ember.belongsTo(Projects, {key: 'project_id'}),
I have to do some manual stuffs because of this change.
Sorry for the late response - I got caught up with some work issues. I'm glad you found a workaround. EAK is constantly changing so I'm sure more surprises are on the way.
I'd be more than happy to help you out anyway I can. Sometimes it's nice to have someone else get their eyes on it. I come from a .NET and RDBMS background, but I've been playing in the javascript world for some time and the mongo world for about a year. Javascript and mongo are starting to become my preferred stack for development.
Moving from a RDBMS to Mongo is no easy task - in config or mindset. When I am needing to decide if something needs to be embedded or not, I always start from the client side to find out how the data will be accessed. If it's better to store it all in one document set then so be it.
Just remember that the beauty of mongo is that it is schemaless.
There are few burning issues, I need a second eye:
I was able to make it work by adding the following into the project.new controller:
I placed that code in the newSprint action before anything else. It could honestly go in the activate method for a route or the init for a controller, just as long as it gets called so that correct type gets referenced in the belongsTo.
This is definitely an issue with the resolver still. I am going to update my app to the latest EAK to see if I encounter any issues. I did still notice that you aren't using the ember-resolver, you still have a reference to the resolver.js, check out their bower.json to get the reference on the EAK repo. I'm not sure if that is the complete problem but there is definitely something happening upon initialization of the models that is not allowing the full reference to the subclass of the projects model to be passed in to create the belongsTo relationship. Strange because it is literally only the belongsTo relations that are affected.
Also just curious, why are you separating out sprints from the projects in the database? Do sprints ever need to be referenced without finding a project? If you don't really have a need to separate them out then I would look into embedded records. It would save you some query hassle on the backend since all of the sprints can be pulled in with their parent project. Again just curious if you have a design constraint that causes them to be separate. I make pretty heavy use of embedded since I am using mongo.