Hi Isomorphic,
I read your new blog post about Relation Fields and 1:n and n:m editing and tried the samples, e.g. this one.
It's working as expected, so this is a great feature. Also having the SetFilterItem, which is something I missed for a long time, is great.
I also read the Relations docs, especially the m:n part. What is not clear to me from the DSRequests I can see in the Developer Console for the multiPickerFields example is the requests in the background.
When I edit e.g. "Upgrade Postgres" and add a 4th team member, this is the update request in the Developer Console:
At first sight, this looks like a multiple field that will get the string value "4, 182, 256, 269" in the DB, but I'm pretty sure this is not the case, as there is also a "teammembers_relation" DataSource in the sample. Which of course is much better than a concatenated string.
My next question then is how the update works? Do you check presence of the needed entries in the m:n table with a select and then add only the missing entries?
Do you take the set difference from data and oldValues?
Of course I could install the eval and just look at the server logs, but perhaps this is also interesting information for the Relations docs.
Regarding the sentence "if any other information is stored in the "join" dataSource, it is no longer a many-to-many relation but two separate many-to-one relations." in those docs:
Is there a possibility to actually save extra information in the m:n table e.g. "hours per week employee is working for that team" or "is team lead"?
If not, and one has to model mentioned two separate many-to-one relations, could you also include a sample for this? I think that a lot of use cases will actually require these extra information.
Overall: Yet another great feature that will make application development easier and faster and more declarative.
Best regards
Blama
I read your new blog post about Relation Fields and 1:n and n:m editing and tried the samples, e.g. this one.
It's working as expected, so this is a great feature. Also having the SetFilterItem, which is something I missed for a long time, is great.
I also read the Relations docs, especially the m:n part. What is not clear to me from the DSRequests I can see in the Developer Console for the multiPickerFields example is the requests in the background.
When I edit e.g. "Upgrade Postgres" and add a 4th team member, this is the update request in the Developer Console:
Code:
{
dataSource:"teams_relation",
operationType:"update",
componentId:"teamsGrid",
data:{
TeamId:4,
EmployeeId:[
4,
182,
256,
269
],
EmployeeName:"Charles Madigen, Tamara Kane, Christian Jeansonne, Anna Andrews"
},
textMatchStyle:"exact",
willHandleError:true,
showPrompt:false,
oldValues:{
TeamName:"Upgrade Postgres",
TeamId:4,
EmployeeId:[
256,
269,
4
],
EmployeeName:[
"Christian Jeansonne",
"Anna Andrews",
"Charles Madigen"
]
},
My next question then is how the update works? Do you check presence of the needed entries in the m:n table with a select and then add only the missing entries?
Do you take the set difference from data and oldValues?
Of course I could install the eval and just look at the server logs, but perhaps this is also interesting information for the Relations docs.
Regarding the sentence "if any other information is stored in the "join" dataSource, it is no longer a many-to-many relation but two separate many-to-one relations." in those docs:
Is there a possibility to actually save extra information in the m:n table e.g. "hours per week employee is working for that team" or "is team lead"?
If not, and one has to model mentioned two separate many-to-one relations, could you also include a sample for this? I think that a lot of use cases will actually require these extra information.
Overall: Yet another great feature that will make application development easier and faster and more declarative.
Best regards
Blama