Link Table State Field Values Being Reset Using Mjoin
Link Table State Field Values Being Reset Using Mjoin
Hello,
I have what I think is a rather unique problem I'm trying to solve. I have a set of tables of business location
s, a table of predefined amenity
s that can be at any location
, and tables for predefined status
s and note
s that each amenity
can have, per each association with a location
.
I'm using a link table to make the associations between each location
and each amenity
at that location, along with the status
and note
state for that amenity
"instance".
Here's what that looks like:
location_amenity
id |location_id|amenity_id|status_id|note_id
---+-----------+----------+---------+-------
1| 1| 2| 1| 1
2| 2| 3| 3| 3
3| 3| 1| 2| 8
4| 4| 2| 1| 6
5| 5| 3| 4| 1
6| 6| 1| 1| 2
7| 7| 2| 1| 1
8| 8| 2| 2| 4
9| 9| 1| 1| 2
I'm using an Mjoin to manage the associations, like so:
Editor::inst($db, "location")
->fields(
Field::inst("location.id"),
Field::inst("location.title")
->validator(Validate::required()),
Field::inst("location.address")
->validator(Validate::required()),
)
->join(
Mjoin::inst("amenity")
->link("location.id", "location_amenity.location_id")
->link("amenity.id", "location_amenity.amenity_id")
->fields(
Field::inst("id"),
Field::inst("title")
)
)
->process($_POST)
->json();
The issue comes when a new amenity
is added to a location
, the status_id
and note_id
fields get reset on existing location
amenity
s because (as mentioned in the docs), the association rows are deleted, then recreated whenever a change is requested for the given location
.
The only ways I can think of to prevent this from happening is to either:
1. Restructure my data/tables another way that I haven't been able to wrap my mind around yet
2. Somehow intercept the Mjoin operation, record the existing status_id
and note_id
values, then tell DataTables to use those values in the newly created association rows.
So far I'm at a loss as to how to go about either of these options, but I was wondering if anyone here could provide any wisdom.
Thanks so much!
-Tim.
Answers
Hi Tim,
I was fiddling around a little with an E/R diagram but I couldn't really make it work because
"per each association with a location" makes it difficult. You would need link tables with more than two columns which doesn't work as far as I know.
You could use Editor event handlers to
- save the two values in Session Variables (if you use PHP for example)
- update the link table with the saved values after execution of the Editor update with the mjoin.
The other alternative is you get rid of the mjoin by putting focus on your link table: That table then would have to be the table that is edited primarily. The other tables are just left joined. I have been doing this from to time in cases like yours. But this can be quite tricky ...
Here are the event handlers for my first suggestion:
https://editor.datatables.net/manual/php/events
You could use "validatedCreate" and "validatedEdit" to save the values that will be lost unless you send them to the server anyway. And then "writeCreate" and "writeEdit" to update the link table with those values again.
Here is some sample code from my own coding showing an UPDATE statement using Editor's "raw" method. I am using some of the values submitted to the server by Editor but also values that I posted to the server plus the Session ID.
Here is where the two $_POST variable get posted from the client. You might be able to use this to post the values that are missing later on after the Mjoin.
Here is another one that emulates an Mjoin in a read-only situation where the "real" Mjoin wouldn't work also using the "raw" method.
To select a single value you would only need to replace "fetchAll" with "fetch" like in here:
Good luck!
Roland
Forgot to mention that Editor also has its own methods for INSERT and UPDATE.
Here is an example which is part of my solution to implement soft deletes of contracts and files so that nothing ever gets deleted physically.
I also found the Editor SELECT method. Never used that one before
You've given me a lot of good stuff to sift through, thank you Roland! I'll tinker with these and report back.
Thanks again!
-Tim.