save($data) not creating columns in table
Permalink
I am trying to save information to the blocks table. I haven't been able to find any documentation on this and so I need some help. I was assuming the following
would automatically add the the "gallery" column to the table if it did not exist. Unfortunately when the function runs it generates an exception error:
Fatal error: Uncaught exception 'ADODB_Exception' with message 'mysql error: [1054.....
The only way I can get it to run is to manually create the columns. Is there something missing? how is the block meant to create the columns automatically?
function save($data) { $args['gallery'] = "GALLERY TEST"; parent::save($args); }
would automatically add the the "gallery" column to the table if it did not exist. Unfortunately when the function runs it generates an exception error:
Fatal error: Uncaught exception 'ADODB_Exception' with message 'mysql error: [1054.....
The only way I can get it to run is to manually create the columns. Is there something missing? how is the block meant to create the columns automatically?
I read over that page several times thinking I was missing something simple. But I have found the problem.
I added the appropriate columns to my db.xml after the block has been installed. From what I can ascertain db.xml is only ran during the install of the block. I needed to remove the block and reinstall it for db.xml to add the new columns to it's table.
I guess this is a safety measure to prevent any other areas where the block has been used from breaking, but what happens when someone releases a new version of a block? Do we need to create a whole new table for the block and have the user manually go through and re-enter the information?
I feel this is counter productive to what my understanding of what concrete5 is about. If what I am saying is correct, can I suggest the following:
add a required "version" field to the block.
When the user goes to the dashboard and selects the block, concrete compares the version stored with the new version it is reading from the controller. If it is a later version an update button is displayed. When clicked it reads a file called update.php and the new db.xml.
The update.php file holds all the default values for the columns and a update() delegate function.
Through SQL for every column in the db.xml it looks to see if the column exists in the table, if it doesn't it adds it. At the same time it adds the default value to every row from the update.php file. The method update() can perform any other maintenance the programmer needs.
Of course the default values could also be integrated into the db.xml file.
At least this way users keep their information and the new block can be used.
Any thoughts or comments???
I added the appropriate columns to my db.xml after the block has been installed. From what I can ascertain db.xml is only ran during the install of the block. I needed to remove the block and reinstall it for db.xml to add the new columns to it's table.
I guess this is a safety measure to prevent any other areas where the block has been used from breaking, but what happens when someone releases a new version of a block? Do we need to create a whole new table for the block and have the user manually go through and re-enter the information?
I feel this is counter productive to what my understanding of what concrete5 is about. If what I am saying is correct, can I suggest the following:
add a required "version" field to the block.
When the user goes to the dashboard and selects the block, concrete compares the version stored with the new version it is reading from the controller. If it is a later version an update button is displayed. When clicked it reads a file called update.php and the new db.xml.
The update.php file holds all the default values for the columns and a update() delegate function.
Through SQL for every column in the db.xml it looks to see if the column exists in the table, if it doesn't it adds it. At the same time it adds the default value to every row from the update.php file. The method update() can perform any other maintenance the programmer needs.
Of course the default values could also be integrated into the db.xml file.
At least this way users keep their information and the new block can be used.
Any thoughts or comments???
Ah.
I see why you were trying to make columns on the fly now.. Yeah - that makes sense if your worried about upgrading blocks as well as the core, which ker-duh we should be.
I'm gonna turn your post into a new thread because I think this deserves more discussion.
thx!
-frz
I see why you were trying to make columns on the fly now.. Yeah - that makes sense if your worried about upgrading blocks as well as the core, which ker-duh we should be.
I'm gonna turn your post into a new thread because I think this deserves more discussion.
thx!
-frz
been through there?