Backbone.Relational.store #450

Closed
USvER opened this Issue Apr 4, 2014 · 12 comments

Comments

Projects
None yet
4 participants

USvER commented Apr 4, 2014

So, i had many issues like "duplicate id" and i was fixing it by finding cached models in the store.
But now i know why this is wrong... My models can come from different source, like:

/users/:id/assets
/pages/:id/assets

So there is a problem if i get asset from store and delete it, what asset do i deleting?
The last one cached! It's wrong...
So either store should test uniquness by id and url
Or i should disable caching all together...

Any ideas? Please help...

Collaborator

philfreo commented Apr 4, 2014

It is unique by model type + id
It sounds like you should be using 2 different Model types (UserAsset and PageAsset or something)

USvER commented Apr 4, 2014

Same model type on different url seems legit to me... I know that copy paste will help... but it does not feel right...

--- Исходное сообщение ---
От кого: Phil Freo
Дата: 04 апреля 2014, 23:24:55

It is unique by model type + id
It sounds like you should be using 2 different Model types ( UserAsset and PageAsset or something) —
Reply to this email directly or view it on GitHub .

Collaborator

philfreo commented Apr 4, 2014

don't think that's a good idea since you could also have cases where you generate a URL that doesn't represent a different model type, by just passing different querystring parameters

USvER commented Apr 5, 2014

Sorry can't understand... So you suggest to copy-paste one model type for every URL?

USvER commented Apr 5, 2014

As a quick fix for this: extend models to new names, so they have their own scoping in the store.

This is not so bad hack, but still smelly...

BTW... This #368 issue can be closed, as i'm using extending with no problems...

USvER commented Apr 7, 2014

NO! IT'S NOT A FIX!!!
Here is why:
So i have

/user/1/assets
/user/2/assets

if they both have the same asset the store will contain only the first one loaded...
And if i call destroy on that.. i will destroy the first one loaded and not the one i get from the URL...

I think this is the major bug...

Guys what to do... My project is starting this week... this thing is blocking the whole process...

USvER commented Apr 7, 2014

Is threre a function that i can override wich defines where to put\get model in the store? So i can override the default modelType+Id beheviour?

Or i guess it's time to move to Backbone.Associations? As i understand correctly it does not provide store, and you have to do it manualy.

Owner

PaulUithol commented Apr 7, 2014

Sounds like the issue here is with your data. If these models are actually different entities, why are you using the same Backbone model? And if that is actually the desired behavior, why are their ids overlapping if they are different entities? Shouldn't you be using full resource_uri's as ids then?

Owner

PaulUithol commented Apr 7, 2014

Also, couldn't the submodels feature be what you're looking for? See http://backbonerelational.org/#RelationalModel-subModelTypes

This allows for mixing different model types within a single relation.

USvER commented Apr 7, 2014

It's the same model, but in different places identified by URL...
It's not a different model, or a submodel.. it's absolutely the same model but on different urls
So if i have assets model on "/users/1/assets/1" and the same model on "/users/2/assets/1" i want my delete methods to go to the respective urls and not on the firs one loaded!

It's a nested resources nothing special!
UPDATE:
Ok, i'm not exposing join table ids... but they can overlap too... so it's not a cure to this issue!
UPDATE2:
Ok, maybe if i expose the join tables as api enpoints, and create it as standalone models, then it can work? i think =\

@bpatram bpatram added the question label Mar 16, 2016

Collaborator

bpatram commented Aug 23, 2016

Closing due to age

@bpatram bpatram closed this Aug 23, 2016

USvER commented Aug 23, 2016

@bpatram my project in production with this bug for two years, but since it's not my pain anymore it's ok!

I think this bug still valid.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment