Module's install/remove

lirit

Hey,

I'm just wondering what would be a good method to follow for a removal of a module?
Meaning, when I install a module, I work with it (add data), I then figure out I need more fields for example, so I code it, then do re-install of the module or remove-and-install but that results in removing all of the module's entries. So for the current testing phase, that's somewhat ok but I'm thinking ahead, when I'll have to issue a newer version, how would that work? upon removal of the older module all records of that module will be lost.

Regards,
Liran.

shacky

Hi,
I updated SF SVN, please get newest revision and go to modules/Tests/Tooltip - there is an example of module versions usage.

Paul

lirit

It was more of a theoretical question of how to deal with it but I'll review the sourcecode,
thank you.

Regards,
Liran.

lirit

Hey,

I had a glance at it, seeing the different functions for upgrade and downgrade but that's a bit off from my main question and main concern which is about the data saved in the database.

To explain it better, let's forget about versions for now. I am developing a plugin with 1 field, I use it for a while and enter records, then I realize I need another field, I change what is necessary in the source code and then I re-install it from the administration -> modules section - at this point, I am losing my previous records, and that is due to the fact that in install() and in uninstall() im doing:



Utils_RecordBrowserCommon::install_new_recordset('insurance_polisa', $fields);

and then



Utils_RecordBrowserCommon::uninstall_recordset('insurance_polisa');

Which removes the records table.
Is there a way to re-install the plugin without having to do install_new_recordset? or rather, if I do a install_new_recordset on an existing recordset (meaning, I didn't do uninstall_recordset on the uninstall of this plugin), will epesibim framework know how to "continue" from that last point and add the further fields necessary to the existing table records?

Regards,
Liran.

shacky

Hi,
there are, in RB, methods like:



Utils_RecordBrowserCommon::new_record_field('insurance_polisa',

        array('name'=>'asdfg', ..... <field def like in install_new_recordset>)); 

Utils_RecordBrowserCommon::delete_record_field('insurance_polisa','asdfg');

Utils_RecordBrowserCommon::set_display_callback('insurance_polisa','asdfg',array(<callback>));

Utils_RecordBrowserCommon::set_QFfield_callback('insurance_polisa','asdfg',array(<callback>));

You can update your RB recordset definition with it. Field position can be defined with 'position' key and integer or existing field name as value.

You can create patches like in patches directory (svn version), use module versions, or if you use it only in development you can call this methods in any callback - call it with epesi UI by entering view generated by it.
Please remember to update your install file also.

Regards
Paul

lirit

Sorry for the late reply.

So, until now I've been doing in my plugins:



		$fields = array(

			array('name'=>'Customer', 	'type'=>'crm_contact', 'param'=>array('field_type'=>'select', 

				'required'=>true, 'extra'=>false, 'visible'=>true), 'visible'=>true, 'required'=>true, 'extra'=>false,

				'display_callback'=>array('Insurance_PolisaCommon', 'display_contact_name'),

				'QFfield_callback'=>array('Insurance_PolisaCommon', 'QFfield_contact_name'),

				),

			.... more plugin fields ... );

		Utils_RecordBrowserCommon::install_new_recordset('insurance_polisa', $fields);

And what you are suggesting now is that, when I work on a new version what I should have install() method is calls to new_record_field() and delete_record_field() since the recordset is already present in the previous (first plugin version).

Is this correct?

lirit

Though haven't gotten your reply on this, I'd like to add a couple more questions:
Is there also an update_record_field? which might be required in the case of when I added a field using new_record_field() and in a newer version I need to set the field's length from X to Y.

Secondly, regarding plugin versions.
Taking a look at the Tests/Tooltip plugin I see that the implementation of the versions is that the file names end with the version number (i.e: Tooltip_0) but there is only one install file (TooltipInstall.php) which has information for both versions, though that probably won't be the case since I will want to have different install files so I'm guessing it's possible to have those separate for each version, right?

(also, is the naming convention the default and only way for versions or is it possible to put versions in different directories?)

Thanks.

shacky

Hi,
There is only one install file, because update just modifies previously created database/configurations in install method. If you would like to have new major release with different point of view, please create new module (ex. Tooltip2).
Update is good if you would like to add/delete some field, table, modify user interface (different main class, that provieds UI). In update method you can also modify existing data (for example you forgot about some keys, or you would like to change unique key...).
For advanced dedicated features we use clear SQL, you can assume what database engine is used by your customer.
RecordBrowser is great for fast scratch of processes in company, for customizations sometimes it's necessary to use SQL.
Arek will give you some details about future of update_record_field in RB, currently there is no such method.

There is no way to place different versions of One module in different directories, but you can always create new module...

Paul

ethnar

As for modifying params - it's not something I'd like to put in mainstream. It strongly falls in line with changing type or essence of the field, which may cause some present values invalid or inaccurate.

For the matter of text field length, if that's just one-time case, I'd suggest to call appropriate SQL queries to modify the param of the field (in <recordset_name>_field table) and change field length in <recordset_name>_data_1 table. Now if that module should or shouldn't revert those changes on uninstallation - that's a big question. If you do that, you are likely to create mechanism to loose data. If you won't - I'd rather consider it a simply patch for selected installations.

Kind regards,
Arek

Epesi ENS | Epesi Academy | epesi.cloud PaaS | GitHub

Help Me! | Download from SourceForge