vtiger

[mikecrowe]

Hi vtiger team,

Have we figured out yet how we are going to migrate data? I have 20-30 custom fields I am concerned about.

Mike

[jeffk]

A timely topic, mike. Previous posts I made on this topic conveyed my mistaken impression that PHP ADODB had some sort of schema migration support. I think I projected that wish because you had brought up schema migration before, and migration is a major stopper issue for me right now.

I went looking for adodb schema migration mentions, and didn't find them:
http://phplens.com/lens/adodb/docs-adodb.htm
http://www.google.com/search?q=adodb+php+schema+migrate
Its kind of a hard thing to search for; since the microsoft flavor of ADO.net *does* address schema migrations.

I've been completely satisfied with Vtiger 4.2 alpha's fitness for my 2-user early adopter deployment for about a month now. The only thing holding me back is that after every change to the data layer, it seems that the tester's only recourse is to dump their database and start over. I don't know how anyone gets any real-world testing done this way.

I'd like to ask the vtiger team to take a look at schema migration as part of their development process, not something that gets done just before a release. I'd like to see any change to the schema increment the schema version number, and accompanied by a small migration change script, an incremental version of whatever they're using now.

I know that this sounds like a lot of developer overhead, writing a incremental migration for every change! But I've seen projects that do it, and the benefits are apparent:

- Software is usually in a near-releasable state. If you get a big job with a crushing deadline, your emergency release cycle is that much shorter.

- Migration steps are smaller, and generally all developers who are adding features to the data layer will learn how to write their own. The migration follows along with each checkin to the data layer. The process becomes distributed, instead of piling up on the desk of the one guy who knows how to do the migration script.

- Use cases like mikecrowes' who have custom fields and may be working with branched source code, can generally manage a small patch to one of the migration steps, or the insertion of a new step, and accomplish their migration that way.

- As I mentioned, I could do a lot more testing of vtiger if I could use it with real world data. I want to track and test the CVS version, because the vtiger devs are turning out a ton of great code at a rapid pace. Aside from the lack of incremental migration, I would gladly have worked with the rough-edged version this past month.

[mikecrowe]

Did you read my post:
http://www.vtiger.com/discussions/viewtopic.php?t=1420
and
http://www.vtiger.com/discussions/viewtopic.php?t=1439?

That shows how ADODB can generate the update queries.

What we need the VT team to address is moving the custom fields numbering before they get overwritten. I discussed this in the above, and Richie will be looking at this (I hope :).

Mike

[indigoleopard]

Hello Team!

It is one of the topmost priorities for us Team. If it comes to it, then even the release will get postponed if the migration is not satisfactory.
This is just to state the level of importance that we attach to this.
Product continuity demands migration.
It will be taken care in right earnest and we will be making the migration script available for testing too so that we can get the feedbacks unlike in 4.0 GA migration.

Richie