Optionally save objects in a (non temporary) directory

[molok]

Hi talek, while I still have not migrated to vorax4 (still using vorax3) I'm looking forward to it. A feature I think would be useful would be to optionally save objects source in a non temporary directory, to create a structure like this:

${vorax_save_source_dir}/DB_INSTANCE/SCHEMA_X/packages/PKG_FOO.bdy
${vorax_save_source_dir}/DB_INSTANCE/SCHEMA_X/packages/PKG_FOO.spc
${vorax_save_source_dir}/DB_INSTANCE/SCHEMA_X/functions/P_FOO.prc
${vorax_save_source_dir}/DB_INSTANCE/SCHEMA_X/procedures/F_FOO.fnc
${vorax_save_source_dir}/DB_INSTANCE/SCHEMA_X/tables/FOO.sql
${vorax_save_source_dir}/DB_INSTANCE/SCHEMA_X/views/VFOO.sql
${vorax_save_source_dir}/DB_INSTANCE/SCHEMA_X/triggers/TR_FOO.sql
${vorax_save_source_dir}/DB_INSTANCE/SCHEMA_Y/tables/FOO2.sql
....

This way you just need to have vorax_save_source_dir under revision control to keep track of development, and you can access objects for quick reference even without a connection with the DB.

Thanks for your effort, I really appreciate your work.

[talek]

Hi Alessio,

Thanks for your feedback!

There are a few changes in Vorax4 which might be relevant in this context. First of all, Vorax4 does not open the database definition in a temporary location anymore. The current directory is used. In addition, Vorax4 sets the ground a bit for working with a source control system as explained here (please see the last paragraph).

What is missing indeed is the possibility to automatically save these database definitions in a folder tree structure, similar with the Vorax database explorer: packages under the packages folder, tables under tables etc. However, this layout is a personal choice. As far as I'm concerned, I always save all database scripts in the same folder and I distinguish them by file extension: pkg for packages, typ for types etc. Nevertheless, I open the definition from the database explorer, but the local file is opened instead (as described within the docs).

If you need to save each type of database definition in its own folder then I would simply rely on the local file-system only and open each definition as a file using your preferred file explorer (e.g. NERDTree). If you need to edit that definition, that would be the right approach anyway, because those changes need to be propagated to your source repository. Editing and saving the changes into the database only would be a mistake, right? If you want to have a quick look at the definition as it is now in the database then you may force this using VORAXEdit!.

So, before anything else, I wanted to let you know what are the options now in Vorax4. My main concern is that the tree-like folders structure might be too specific: for example, some may want packages under "PACKAGES", while others under "PLSQL Modules". Thus, the question is: should Vorax assume a particular folders layout or let users choose whatever they think it's best for them?

Talek.

[abolognino]

I wrote a patch for saving objects in a custom place btw: https://github.com/molok/vorax4/commit/a10d974fe792a5348d0f7ac2704b5f6ef9116180

[talek]

Hello,

Thanks for the patch. It seems to provide a way to save DB source files in a custom place taking into account the target connected DB (it is a bit different than the initial request). I like the idea. To some extent this was already possible by using the VORAXAfterConnect hook. For example, you may add this to your .vimrc:

function! VORAXAfterConnect(user, db, role)
  if vorax#sqlplus#Properties()['db'] == 'mydb'
    exec 'cd /home/talek/oracle/mydb'
  endif
endfunction

On the other hand, the VORAXAfterConnect hook doesn't guarantee that the DB object scripts will be saved on the dedicated location if the current directory is being changed by other means (NERDTree, vim itself, etc.). I think the best would be that instead of g:vorax_save_source dictionary variable to go with a g:vorax_save_prefix string variable which can be initialized in the VORAXAfterConnect hook. It would be more flexible in the sense that you may come up with a more complex logic in deciding how/when to set this prefix, right into the hook function.

What do you say?