Question about 'upgrade' process for a Fabrik App (not Fabrik application)

[bggann]

Hi folks,

If you've been tracking this forum you know I have a large form system that has been causing problems for some of my "customers" as they enter "resources" in a repeating group. The issue is performance for large agencies that have lots of resources.

I'm planning a re-structure of the database/list that will allow those customers to break their submission into multiples. This will have the benefits of:

1. Improving performance
2. Allowing them to enter resources in logical "groups" that makes it easier for them to track.

To do this I will have to add 2 fields to the main "list" and database, and change the access for agencies logging it to show the list filtered by their ID rather than the single record related to their ID.

This will take a number of hours of work, followed by "testing" and verification. It is unlikely I can get the work and required testing done in less than a few days. (partly because the testing is conducted by several people).

Since the system is live, I have 2 choices:
- Take the system down for several days while I make the upgrade. (a non-starter) so that no data is added to the underlying system during the work.
or
- Do the update on a backup/development system, carefully tracking what I do, complete the testing, then take the live system down for hours and "replicate" my changes on the live system.

That later feels dangerous to me. What if I miss a step and don't precise replication. I could bring the live system back up with a defect.

-------
So. Here is the question.

Is there a way to:
- Do the design/upgrade work and testing on the backup system.
- Then, once I'm happy,
* Take the live system down.
* Transfer the Fabrik app from the test system to the live system (maybe using a package?)
* Make the required "database" changes (adding 2 or 3 fields) in php but preserving any data that has entered in the meantime.
* Bring the live system back up.

This would mean
- I do the changes 1 time and those changes are tested.
- Don't loose any data
- Minimize down time.

The danger I see is the Fabrik App and Database would be "out of sync" for a bit.
---
Note - in either case, I will have to make data changes in phpadmin in the underlying database to add the data that is missing.

Thoughs?
Bob

 

[troester]

3rd possibility:

• create you dev system, make your changes, track all modifications done on your customer data via phpmyadmin (e.g. copying data from existing columns to new ones...)
• take the live system down,
• truncate the data tables on your dev system, import the recent data from the live system, do again the phpmyadmin tasks
• switch the dev system to be the new live system

This way you don't have to redo the changes in Fabrik (but have to (re-)import the data), phpMyAdmin tasks have to be done in any case.
Your old live system isn't touched, so you can switch back instantly.

 

[bggann]

3rd possibility:

• create you dev system, make your changes, track all modifications done on your customer data via phpmyadmin (e.g. copying data from existing columns to new ones...)
• take the live system down,
• truncate the data tables on your dev system, import the recent data from the live system, do again the phpmyadmin tasks
• switch the dev system to be the new live system

This way you don't have to redo the changes in Fabrik (but have to (re-)import the data), phpMyAdmin tasks have to be done in any case.
Your old live system isn't touched, so you can switch back instantly.

Troester,

I like this approach. Thanks

 

[cheesegrits]

An alternative might simply be to not join the "resources" table to the main table. Just maintain it as a separate table, still with a foreign key to their main table row. Just don't include all that data on the main form



Sent from my HTC 10 using Tapatalk

 

[bggann]

Troester,

I like this approach. Thanks

This is what I did. The changes required only 3 new fields on one table and the data that goes in them was simple. So, what I did was:
- Get the upgrade working on a staging site with data from a clone. Note - the staging site was on the same server, so phpadmin saw both databases.
- When it was ready - I took down the main site.
- I made a backup of the live site database.
- I added the 3 fields and populated them.
- I moved the 2 changed tables from the backup to the new site.
- I added the new records from newly registered users to the user table on the new site.
- Verified the new site was working with all the 'changed' data
- Moved the new site to the 'main site' using akeeba.

Worked like a charm and was not difficult.

 

[bggann]

An alternative might simply be to not join the "resources" table to the main table. Just maintain it as a separate table, still with a foreign key to their main table row. Just don't include all that data on the main form



Sent from my HTC 10 using Tapatalk

I need to better understand how joins and such work in Joomla and Fabrik. I understand SQL just fine, but there my understanding of how various elements relate is not clear.
For instance, the 'resources' are in a repeating group that is included in the main form. The data (underlying in SQL) is in 2 tables with an id and a parent id field that is the 1:many link.
It sounds like I could move that group off the main form and build a 1:many join somehow.
How do I do that. I think it may be valuable in a project I'm working on.
Also - how will a user who enters the "main" form add data to the "joined" form since it is no longer a repeated group.

 

[cheesegrits]

A repeating group in Fabrik is just a one-to-many join to a separate table. Normal parent / child relationship. Child row has a foreign key (FK) pointing to the PK of the parent. When you create a repeat group in Fabrik, we just automagically create that child table and add the FK element (parent_id) for you, and handle maintaining the relationship by setting the parent_id to the PK of your main table's row.

But there's nothing to stop you maintaining your own FK relationship, with the child table as a separate List in Fabrik. You could test it, by just creating a new List, and select the table we created for your repeat group - it'll be named something like <main table name>_<group id>_repeat.

You'll have to set up the element types again, as they'll just be set as simple fields, for the most part (unless we can figure the element type from the database column type, like datetime). And for the parent_id, make that a join element to your main table. If you then add a resource through that list, and manually select the "parent" ... then go and load up that record in your main list, you'll see it will have picked up the new resource you added.

I'd suggest doing this on an Akeeba clone of your site, btw, so you dont risk blowing anything away.

What you can then do is remove the existing join on your main list. And instead, set up "related data". Check the related data tab, to the right of the Joined Data tab. You should see your new 'resources' list & form shown there, as it has a join to your main table. Set it to show the "list". Then when you display your main list, you'll see a button which takes you to a filtered view of the resources "owned" by that row. Adding the "form" for related data will open a form to add a new resource, with the FK automatically set to that main parent row.

That way you can maintain the relationships, without butting up against the resource problems of trying to have too much repeated data integrated into the main form.

-- hugh

 

[bggann]

Thanks - I'll take a look at that. This is for a new "clean" system, so it is easier to play. The upgraded site has been purring along just fine. Not a peep from my 'agencies', which is good. Stuff is just coming in.