How to UPDATE block table instead of inserting a new row?
Permalink
Whenever I edit a block, it seems to insert a new entry in the database table. Instead of inserting a new row, I'd just like to update the same entry in the table. Is this possible? Adding a new row every time a block is edited creates redundant entries in the database. Is this an intended behaviour for some reason? I simply can't get my head around this issue.
I'm still unable to find an answer to this. Does anyone know if this is a normal behaviour?
Hi,
this is normal behavior because Concrete5 keeps track of modifications to page sin case you want to go back to a previous version of the page.
Every time you edit the block it gets assigned a new block ID. If you ever decide you want to go back to a previous version of your page, the appropriate block Id will be used. So it's not redundant, it's a safety measure :)
this is normal behavior because Concrete5 keeps track of modifications to page sin case you want to go back to a previous version of the page.
Every time you edit the block it gets assigned a new block ID. If you ever decide you want to go back to a previous version of your page, the appropriate block Id will be used. So it's not redundant, it's a safety measure :)
Hmmm.... so that means the block table can significantly get large.
I am currently working on a block where users can add unlimited number of different sets of fields. The secondary block table stores field name and value associated with those various input fields. Each field set has 5 different fields and they can be cloned and added multiple times. If the users are to save 10 sets of those fields, it will be storing 50 entries in the database in one go. So every time they edit any of the fields, there will be 50 additional entries. Now that's going to make that particular database table massive! Now how do I tackle this situation? Should I have stored serialized data in the database instead, so that only one entry is stored in one edit?
So if new entries are created in the database for every edit, then I should not delete the block tables even after uninstalling the block? With my current block, I've made it in such as way that uninstalling will remove all the tables associated with it.
I am currently working on a block where users can add unlimited number of different sets of fields. The secondary block table stores field name and value associated with those various input fields. Each field set has 5 different fields and they can be cloned and added multiple times. If the users are to save 10 sets of those fields, it will be storing 50 entries in the database in one go. So every time they edit any of the fields, there will be 50 additional entries. Now that's going to make that particular database table massive! Now how do I tackle this situation? Should I have stored serialized data in the database instead, so that only one entry is stored in one edit?
So if new entries are created in the database for every edit, then I should not delete the block tables even after uninstalling the block? With my current block, I've made it in such as way that uninstalling will remove all the tables associated with it.
why not run an update query instead of insert upon edit? That is what I do on a custom 'Attendance' block for Pro Events (using the built in Survey block as a base), so people have the ability to change their attendance.
Yes that's what I've been unable to figure out. Every time you press that save button on the block's edit mode, it invokes the save() function in the controller, which creates a new bID in the primary table and this new bID is passed on to the secondary table. That means the old records are never updated. Maybe I am looking at this from a wrong perspective. Could you please correct me? Thanks.
Create your own query in your controller save() function with update instead. Or create an update() function which should be called from the edit view.
Ok... yes I can create an update() function inside edit() function. Are you suggesting something like below?
But I still have parent::save($data) inside the save() function. This will still be called at the end and create a new record. Isn't that so?
function edit() { Loader::model('abc_nav', 'abc_nav'); $nav_data = new AbcNav($this->bID); $nav_data->update(); ... ... }
But I still have parent::save($data) inside the save() function. This will still be called at the end and create a new record. Isn't that so?
If this is a block for your own use, its up to you. But if you intend to release an addon and this block ever gets to the PRB, changing the edit/save function to effectively remove versioning is (as far as I know) extremely likely to be rejected.
I suggest you have a look at the free slideshow add-on that comes with C5, it will show you what they do with multiple table add-ons.
There is more to just the save function though. In some cases, actions other than edit also create a new bID which will not appear in the second table. copying the block for instance creates a new bID in the main table and of course nothing happens in the second table so the block is broken. I think applying a template has the same effect. In both cases though, the function duplicate($nbID) is called with $nbID being the new bID which you can use to update your secondary table.
There is more to just the save function though. In some cases, actions other than edit also create a new bID which will not appear in the second table. copying the block for instance creates a new bID in the main table and of course nothing happens in the second table so the block is broken. I think applying a template has the same effect. In both cases though, the function duplicate($nbID) is called with $nbID being the new bID which you can use to update your secondary table.
