New ID for each fields row in sym_entries_data_# after editing an entry
This is an open discussion with 6 replies, filed under General.
Search
Because the data is deleted and inserted again, I believe. I think it made the underlying system easier, so it always just deletes and inserts, rather than having to insert or update. They’re internal primary keys, so it’s never really been an issue.
Ok, so when there is no direct relationship between the input elements of a field extension and its columns in the db table there still need to be corresponding hidden inputs with the actual values on the publish form.
And I assume that it’s different in events for safety/convenience-reasons. Correct?
Which database column are you referring to? The id
column is purely internal, and I don’t think it is ever actually used. This will auto increment each time you save a section. But the field_id
is won’t change, this is the foreign key from the sym_fields
table, it’s the permanent ID of the field (which you see in the HTML).
Ah, I’m talking about the entry editor and not the section editor.
I’m referring to every column except id
and entry_id
in sym_entries_data_{field_id}
. I’m building a field extension where the columns in the db are an abstracted representation of the actual input elements I show on the edit form. So my first guess to not change the field values in an existing entry was to just not send the data. But then you loose the data.
Wouldn’t you use rows for this instead of columns?
For each entry a field creates a new row (actual data), filling out the columns (model, abstract representation of my input elements). So I use both ;-)
But I don’t want to confuse anybody.
Create an account or sign in to comment.
When an entry gets edited each fields row in symentriesdata_# of that entry gets a new ID. Is there any reason for that? Without thinking too much about it it seems a bit strange to me.