-
Notifications
You must be signed in to change notification settings - Fork 76
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
db can now be switched dynamically on the adapter #89
Conversation
Thanks for putting this together, @olivierchatry. Can you give some more details on why you want to do this? I don't understand the use case. |
Hey ! Sure :) So what I have done is that I have a private DB that can only be accessed from a backend. The backend then create a couchdb for each project, and set the right roles for a given user. ( my users are actually glorified couchdb users). When the user browse the projects, he do not actually open any project, but just browse through what the backend return from the private db. When a user open a project, I actually dynamically change the database (database URL is given by the backend ) object inside the project adapter. This is working quite well right now ( as long as you are sure that their will be only one active project at a time, which is my case, and I would guess the most common case). This allows me to leverage couch security system, as well as having offline possibility with pouch, and the user only have on the local computer what he really needs to have access to. Note that, on the store side, I have also to clear the already loaded project with : this.store.unloadAll('project') |
So ? What do you think ? Is it good enough or should we close the request ? |
@@ -81,7 +87,8 @@ export default DS.RESTAdapter.extend({ | |||
_init: function (store, type) { | |||
var self = this, | |||
recordTypeName = this.getRecordTypeName(type); | |||
if (!this.get('db') || typeof this.get('db') !== 'object') { | |||
var db = this.get('db'); | |||
if (!db || typeof db !== 'object') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
^ makes sense
@olivierchatry This sounds like a great change to me, although if it's an API-level change, then it would also be good to add a section to the README explaining how to use it. The other thing I'd say is that it seems there are a few unrelated changes in here (e.g. code cleanup, ember-data beta 19 fixes), so maybe it would be helpful to break this up into a few smaller PRs? That way, we can just deal with the proposed new feature (swapping out databases), while considering the other changes separately. Does that make sense? |
for (var i = 0, len = this._schema.length; i < len; i++) { | ||
var currentSchemaDef = this._schema[i]; | ||
if (currentSchemaDef.singular === singular) { | ||
return; | ||
isSchemaNew = false; | ||
break; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
^ this code doesn't look equivalent to me. can you explain it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the main problem is that the model name is the same, ( for me 'project' ) which means that the schema does not need to be recreated BUT needs to be applied to the new DB instance ( or else 'rel' is not defined ). That the goal of this code and the code below.
I appreciate you providing some more context for this feature. The tricky thing I think is the interaction with the store, as you alluded to at the end of your description. With this change alone, the store will still reflect any records that were loaded from the previous database. Updates to those records will be saved into the new database, which seems like it would probably surprise the user. Since saves are async, it's possible you'd still get records winding up in the wrong place, even if you had some awareness of the potential for this problem. What if, instead of just observing the db property being set, this feature was activated by a method on the adapter? ( |
Yeah that would make more sense I think. I will wrap that inside a function and see if it works. |
Are |
|
@olivierchatry, this stalled because of the test failures after your last few changes. I think the test failures were caused when you fixed those deprecation warnings — this broke backwards compatibility with some of the versions of ember-data we supported in version 2.x of the adapter. Good news is that we dropped compatibility with those old versions for version 3.0 of the adapter. If you could rebase and squash on top of current master, we could pick this up again. Thanks for your efforts so far. |
# Conflicts: # addon/adapters/pouch.js
Well, not sure what to do ( seems like the build fails because of a dependency that was not fetched ). Should I fake commit to relauch ? or we can close the PR and open it up again ? |
You could |
I manually retried the build. Let's see what happens with that. |
🎉 |
@@ -183,6 +183,31 @@ The value for `documentType` is the camelCase version of the primary model name. | |||
|
|||
For best results, only create/update records using the full model definition. Treat the others as read-only. | |||
|
|||
## Multiple databases for the same model | |||
|
|||
In some cases it might diserable (security related, where you want a given user to only have some informations stored on his computer) to have multiple databases for the same model of data. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo: desirable
And it's green! :) 👍 |
Ah, unfortunately there's a merge conflict, and I'm not really sure what to do in this case: ++<<<<<<< d09cb4c3ed0fab63eca17233efd442f50b989c7b
+ var store = this.store;
++=======
+ var store = this.container.lookup('service:store');
++>>>>>>> fixes livesync for ember data 2.x |
Set to this.store I would guess.
|
This is really awesome! What needs to happen to get this merged ? |
I'm gonna rebase to double-check that the tests are still passing, but then I'm happy to merge. |
If #107 passes, then we're good to go. |
And it's green! :) |
db can now be switched dynamically on the adapter
This patch allows to switch dynamically a pouch DB on the adapter. This can be very useful if you have one model that can represent different databases.