zzzprojects
Add support for lists of primitives
Hi I can't get many-to-many relation to update. Does it suppose to work?
I have wo questions:
- Just to be sure - What is difference between Associated and Owned? (I assumed Associated is correct for situation that a data points another one but the other data should not get deleted when the pointing data is deleted).
- Is there any problem when you use ForeignKey on properties? I suspect that GraphDiff doesn't detect situations where a property is actually binded through a ForeignKey property... (The foreign key property is actually a kind of proxy)...
Hi,
I think many-to-many is supposed to work but not tested (well) yet as issue #30 is requesting tests for this scenario.
The difference between Associated and Owned is - as far as I understand - that Associated asks GraphDiff to only change relations while Owned extends this to change the referenced entities themselves too (change meaning insert/update/delete).
I'm not really sure I understand your second question, but if you provide a (preferably small) unit test for the problematic scenario I'll have a look.
The scenario is having a class with owned collection property. The collection is not fully loaded since there is another collection with ForeignKey attribute that only holds the ids of the entities.
public class TodoList
{
public int TodoListId { get; set; }
[Required]
public string UserId { get; set; }
[Required]
public string Title { get; set; }
public virtual ICollection<TodoItem> Todos { get; set; }
[ForeignKey("Todos")]
public virtual ICollection<int> TodosIDs { get; set; }
}
My question is -- Does it suppose to work when you add ids into TodosIDs? From what I've seen, not quite... It seems that the library doesn't check for a related ForeignKey property when checking a property like Todos... In entity framework it switches to the ForeignKey property...
Hi,
ah, thanks, now I understand. Currently GraphDiff only works with navigation properties, so no, this doesn't work. I've to think a bit about it, but I don't see an immediate reason why this couldn't be implemented for associations.
It can be implemented for every property... When such is found it can be treated as association without relation to the definition. IMO the owner/association is not very clear and I couldn't understand the necessity. I think that's a definition of HasMany and HasOne would be better and will follow Entity Framework schema definitions.
--- Original Message ---
From: "andypelzer" [email protected] Sent: 6 בפברואר 2014 23:01 To: "refactorthis/GraphDiff" [email protected] Cc: "shkup" [email protected] Subject: Re: [GraphDiff] Problem with many to many and a question (#43)
Hi,
ah, thanks, now I understand. Currently GraphDiff only works with navigation properties, so no, this doesn't work. I've to think a bit about it, but I don't see an immediate reason why this couldn't be implemented for associations.
Reply to this email directly or view it on GitHub: https://github.com/refactorthis/GraphDiff/issues/43#issuecomment-34370262
They are actually different things. HasMany is a multiplicity, owned is an aggregate definition. http://stackoverflow.com/questions/1958621/whats-an-aggregate-root
Associated means the entity is not a part of the aggregate to be updated, owned means it is. This means associations only update the references and owned updates the entity details and the references. I have an explanation on my blog.
If you have a list of integer id that has changed would it update it on the db if association is defined ?
--- Original Message ---
From: "Brent McKendrick" [email protected] Sent: 7 בפברואר 2014 09:11 To: "refactorthis/GraphDiff" [email protected] Cc: "shkup" [email protected] Subject: Re: [GraphDiff] Problem with many to many and a question (#43)
They are actually different things. Hasmany is a multiplicity, owned is an aggregate definition.
Associated means the entity is not a part of the aggregate to be updated, owned means it is. This means associations only update the references and owned updates the entity details and the references. I have an explanation on my blog. On 7 Feb 2014 18:06, "shkup" [email protected] wrote:
It can be implemented for every property... When such is found it can be treated as association without relation to the definition. IMO the owner/association is not very clear and I couldn't understand the necessity. I think that's a definition of HasMany and HasOne would be better and will follow Entity Framework schema definitions.
--- Original Message ---
From: "andypelzer" [email protected] Sent: 6 בפברואר 2014 23:01 To: "refactorthis/GraphDiff" [email protected] Cc: "shkup" [email protected] Subject: Re: [GraphDiff] Problem with many to many and a question (#43)
Hi,
ah, thanks, now I understand. Currently GraphDiff only works with navigation properties, so no, this doesn't work. I've to think a bit about it, but I don't see an immediate reason why this couldn't be implemented for associations.
Reply to this email directly or view it on GitHub: https://github.com/refactorthis/GraphDiff/issues/43#issuecomment-34370262
— Reply to this email directly or view it on GitHubhttps://github.com/refactorthis/GraphDiff/issues/43#issuecomment-34408865 .
Reply to this email directly or view it on GitHub: https://github.com/refactorthis/GraphDiff/issues/43#issuecomment-34409040
No it won't, it's quite possibly something we could add support for. Easy way out would be to wrap those ids with the entity and make that collection the association. On 7 Feb 2014 18:18, "shkup" [email protected] wrote:
If you have a list of integer id that has changed would it update it on the db if association is defined ?
--- Original Message ---
From: "Brent McKendrick" [email protected] Sent: 7 בפברואר 2014 09:11 To: "refactorthis/GraphDiff" [email protected] Cc: "shkup" [email protected] Subject: Re: [GraphDiff] Problem with many to many and a question (#43)
They are actually different things. Hasmany is a multiplicity, owned is an aggregate definition.
Associated means the entity is not a part of the aggregate to be updated, owned means it is. This means associations only update the references and owned updates the entity details and the references. I have an explanation on my blog. On 7 Feb 2014 18:06, "shkup" [email protected] wrote:
It can be implemented for every property... When such is found it can be treated as association without relation to the definition. IMO the owner/association is not very clear and I couldn't understand the necessity. I think that's a definition of HasMany and HasOne would be better and will follow Entity Framework schema definitions.
--- Original Message ---
From: "andypelzer" [email protected] Sent: 6 בפברואר 2014 23:01 To: "refactorthis/GraphDiff" [email protected] Cc: "shkup" [email protected] Subject: Re: [GraphDiff] Problem with many to many and a question (#43)
Hi,
ah, thanks, now I understand. Currently GraphDiff only works with navigation properties, so no, this doesn't work. I've to think a bit about it, but I don't see an immediate reason why this couldn't be implemented for associations.
Reply to this email directly or view it on GitHub:
https://github.com/refactorthis/GraphDiff/issues/43#issuecomment-34370262
— Reply to this email directly or view it on GitHub< https://github.com/refactorthis/GraphDiff/issues/43#issuecomment-34408865>
.
Reply to this email directly or view it on GitHub: https://github.com/refactorthis/GraphDiff/issues/43#issuecomment-34409040
— Reply to this email directly or view it on GitHubhttps://github.com/refactorthis/GraphDiff/issues/43#issuecomment-34409312 .
For instance create todos with only the id fields then add them to the collection of todos. If it's associated it won't update the value if the to-do, just the fact that it is now linked to the parent entity. On 7 Feb 2014 18:25, "Brent McKendrick" [email protected] wrote:
No it won't, it's quite possibly something we could add support for. Easy way out would be to wrap those ids with the entity and make that collection the association. On 7 Feb 2014 18:18, "shkup" [email protected] wrote:
If you have a list of integer id that has changed would it update it on the db if association is defined ?
--- Original Message ---
From: "Brent McKendrick" [email protected] Sent: 7 בפברואר 2014 09:11 To: "refactorthis/GraphDiff" [email protected] Cc: "shkup" [email protected] Subject: Re: [GraphDiff] Problem with many to many and a question (#43)
They are actually different things. Hasmany is a multiplicity, owned is an aggregate definition.
Associated means the entity is not a part of the aggregate to be updated, owned means it is. This means associations only update the references and owned updates the entity details and the references. I have an explanation on my blog. On 7 Feb 2014 18:06, "shkup" [email protected] wrote:
It can be implemented for every property... When such is found it can be treated as association without relation to the definition. IMO the owner/association is not very clear and I couldn't understand the necessity. I think that's a definition of HasMany and HasOne would be better and will follow Entity Framework schema definitions.
--- Original Message ---
From: "andypelzer" [email protected] Sent: 6 בפברואר 2014 23:01 To: "refactorthis/GraphDiff" [email protected] Cc: "shkup" [email protected] Subject: Re: [GraphDiff] Problem with many to many and a question (#43)
Hi,
ah, thanks, now I understand. Currently GraphDiff only works with navigation properties, so no, this doesn't work. I've to think a bit about it, but I don't see an immediate reason why this couldn't be implemented for associations.
Reply to this email directly or view it on GitHub:
https://github.com/refactorthis/GraphDiff/issues/43#issuecomment-34370262
— Reply to this email directly or view it on GitHub< https://github.com/refactorthis/GraphDiff/issues/43#issuecomment-34408865>
.
Reply to this email directly or view it on GitHub: https://github.com/refactorthis/GraphDiff/issues/43#issuecomment-34409040
— Reply to this email directly or view it on GitHubhttps://github.com/refactorthis/GraphDiff/issues/43#issuecomment-34409312 .
But associated collection of ids is quite the same as linked entity, only for many entities... I'm trying to understand if there is values based comparison or reference based comparison.. Manual comparison is usually CurrentValues of the db entity compared to the current values of the updated one.. Is this the compare method?
--- Original Message ---
From: "Brent McKendrick" [email protected] Sent: 7 בפברואר 2014 09:27 To: "refactorthis/GraphDiff" [email protected] Cc: "shkup" [email protected] Subject: Re: [GraphDiff] Problem with many to many and a question (#43)
For instance create todos with only the id fields then add them to the collection of todos. If it's associated it won't update the value if the to-do, just the fact that it is now linked to the parent entity. On 7 Feb 2014 18:25, "Brent McKendrick" [email protected] wrote:
No it won't, it's quite possibly something we could add support for. Easy way out would be to wrap those ids with the entity and make that collection the association. On 7 Feb 2014 18:18, "shkup" [email protected] wrote:
If you have a list of integer id that has changed would it update it on the db if association is defined ?
--- Original Message ---
From: "Brent McKendrick" [email protected] Sent: 7 בפברואר 2014 09:11 To: "refactorthis/GraphDiff" [email protected] Cc: "shkup" [email protected] Subject: Re: [GraphDiff] Problem with many to many and a question (#43)
They are actually different things. Hasmany is a multiplicity, owned is an aggregate definition.
Associated means the entity is not a part of the aggregate to be updated, owned means it is. This means associations only update the references and owned updates the entity details and the references. I have an explanation on my blog. On 7 Feb 2014 18:06, "shkup" [email protected] wrote:
It can be implemented for every property... When such is found it can be treated as association without relation to the definition. IMO the owner/association is not very clear and I couldn't understand the necessity. I think that's a definition of HasMany and HasOne would be better and will follow Entity Framework schema definitions.
--- Original Message ---
From: "andypelzer" [email protected] Sent: 6 בפברואר 2014 23:01 To: "refactorthis/GraphDiff" [email protected] Cc: "shkup" [email protected] Subject: Re: [GraphDiff] Problem with many to many and a question (#43)
Hi,
ah, thanks, now I understand. Currently GraphDiff only works with navigation properties, so no, this doesn't work. I've to think a bit about it, but I don't see an immediate reason why this couldn't be implemented for associations.
Reply to this email directly or view it on GitHub:
https://github.com/refactorthis/GraphDiff/issues/43#issuecomment-34370262
— Reply to this email directly or view it on GitHub< https://github.com/refactorthis/GraphDiff/issues/43#issuecomment-34408865>
.
Reply to this email directly or view it on GitHub: https://github.com/refactorthis/GraphDiff/issues/43#issuecomment-34409040
— Reply to this email directly or view it on GitHubhttps://github.com/refactorthis/GraphDiff/issues/43#issuecomment-34409312 .
Reply to this email directly or view it on GitHub: https://github.com/refactorthis/GraphDiff/issues/43#issuecomment-34409670
Yes you are correct CurrentValues is used. GraphDiff does expect a list of entities though, and not a list of primitives. I think this is a good candidate for extra functionality to be added.