Separating installer from a rest of a system

[Alexander Obuhovich]

Right now In-Portal Install/Upgrade wizard is tightly coupled with rest of In-Portal code. In some cases (when database tables are renamed) we have warnings across all of Installer.

I'm proposing to disconnect make Installer script a separate entity, that doesn't base itself on top of kApplication class and even may use it's own SQLLite database if there is a need.

Then when Installer need to make changes to underlying In-Portal system (e.g. rebuild caches), he can create in-portal instance and communicate with it. This is of course not required at all to do database changes.

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Alexander Obuhovich]

We might also consider wrapping table names in sqls in upgrade scripts into "{" and "}" this way we can see where table name is in the sql and manipulate with it.

For example INSERT INTO table1 SELECT FROM table2; query doesn't work, because table2 isn't recognized in the sql and TABLE_PREFIX (e.g. "inp_") isn't added to it.

To solve this we add <%TABLE_PREFIX%> in front of such tables.

Replacing that sql with following: INSERT INTO {table1} SELECT FROM {table2}; we can quickly add necessary changes to table names. For example we had problems with direct upgrade from 5.0.0 to 5.2.0 because table names in upgrade scripts became outdated. With {} scheme we then could have always replaced older table names into newer table names on the go.

Let's don't forget about INSERT into AdminSkins table, where CSS exists with {....} in it too. I think we can do some workaround about it too.

[Dmitry A.]

Was there any need for this?

I know we were thinking about having the ability to installed from Console too in case if we need to automated the process. In case of install from Console we probably don't need to STEPS at all since you can pretty much pre-configure your setup and run the script

DA

[Alexander Obuhovich]

This is a problem, because more versions of In-Portal we release more complicated upgrade scripts became. And I remember that upgrading from 5.1.0 to 5.2.0 became serious problem for us and we needed to change all upgrade scripts.

Having installer as a separate piece of code, that doesn't rely on in-portal would make us possible to do any changes without a risk to break installer, because we're changing some in-portal piece, that installer relies on.

[Dmitry A.]

Thanks for details on your views.

I think we should strongly consider this task for In-Portal 5.3.0, agree?

DA

[Alexander Obuhovich]

Yes. No much ideas about how to implement this separation, but I think we can come up with something in time.