Syncing two different TNG installations

[dlmartin]

I'm considering purchasing a second license and having two sites - one for my family and another branded for my wife's side.

I'd like to have all the data in both trees however.     Is there a way to do this and sync the data back and forth?   Or possibly have two domain names that access the same database?

Is this just a dumb idea?

Thanks,

Dean

[tngrlkrz]

Did you take a look at having two branches, one for you and one for your wife's families and only have one site? Not sure of syncing other data between two sites, but the media folder could be shared in the webspace via symbolic links.

Ron

[Rob Roy]

I have two instances, one for my immediate family and one for the Delvee Family Association.  Both exist together in the same MySQL database; however, they are not synced.  There are several people who exist in both instances.  If I change one, I have to go over and change the other.  Ron is correct, using trees is your best method.

Sailor Rob

[GOGGS]

If you are familiar with some advanced database techniques, there are a few ways to do this. And use a 2nd "root" folder perhaps to make config easy - so /www for one and /www2 for another. Database "views" allow you to mimic a table with a query on a real table. E.g. tng_people2 could be a view where it is defined as 

SELECT * FROM tng_people WHERE GEDCOM = 'xxx'

That way all your data is in 1 database and doesn't require any syncing, etc. but you can have 2 instances or websites.

 

GOGGS

[Adri1]

I'm interested to in this.

I would like to have 2 Trees or 2 sites with one database of possible.

One should be a sort of demo with limited data(no birthdates of deathdates) for users that are not logged in.

The full one contains all data for  registrated users.

Is this possible.

 

 

 

 

[GOGGS]

@Adri1 this idea is very possible, and I can think of lots of ways to do it. But to carry the idea from the original post, if someone wants 2 sites that share the same database, using a second root folder (e.g. /var/www/html2) at the same level as the original would be step 1.  Copy or install the files to the new folder and begin configuring TNG in the 2nd instance - in Setup >> Configuration >> General Settings >> Paths and Folders you would update the Root Path to /var/www/html2 (for example). Next, using phpMyAdmin or similar, create a database view on the same db as the original - you could also duplicate the whole db to a new one, but then you would be updating all of the info in 2 different places. 

A view is basically a saved query in a database that acts like a table. If I wanted to make a view on my tng_people table that had all of the people and wipe out the birthdates (dates are complicated because there are so many and 2 different formats), this is the command:

CREATE VIEW tng_people2 AS 
SELECT ID, gedcom, personID, lnprefix, lastname, firstname, 
birthdate = '' AS birthdate, birthdatetr = '0000-00-00' AS birthdatetr, 
sex, birthplace, deathdate, deathdatetr, deathplace, altbirthdate, altbirthdatetr, altbirthplace, burialdate, burialdatetr, burialplace, burialtype, baptdate, baptdatetr, baptplace, confdate, confdatetr, confplace, initdate, initdatetr, initplace, endldate, endldatetr, endlplace, changedate, nickname, title, prefix, suffix, nameorder, famc, metaphone, living, private, branch, changedby, edituser, edittime 
FROM `tng_people` 
WHERE branch <> 'somebranchname';

Lastly, in the Setup >> Configuration >> General Settings >> Table Names, update the name of the People table to the name of the view just created (e.g. tng_people2).

I did this on my system (without creating the duplicate folder) and it "hides" the people in the branch I excluded, plus nobody had a birthdate.

I've always thought (in professional work) that views were powerful for this usage (especially if you tie permissions to ones you want or don't want people to see). Just make sure you include ALL of the column names from the original table (in the TNG case, anyway), use the correct format for the field type if you are redefining the value of a field (e.g. '' or '0000-00-00' or NULL, etc.), and rename the original fieldname back to itself with the AS directive (birthdate = '' AS birthdate).

Hope this helps!

 

GOGGS

[Clelia]

GOGGS,

Thank you for posting this. It is very helpful as I figure out how to secure the various lines and give different family members different visibility access. I need one line (call it Line 2) to see everything in just their branch but nothing in any other branch. Another line (Line 1) gets to see all data for all lines, including Line 2. It would make my life easier if I could have all the lines point to the same back-end database instead of having separate trees with some individuals duplicated.

Would it be possible to use your scenario to retain full functionality of TNG for the users of the limited tree (i.e. Line 2), with a different installation folder, by creating and referencing views? Would I need to make a view for each of the 37 baseline tng tables? Or are there behind the scenes queries in java or php that reference tables directly and would bypass the views, allowing info from the other lines to be visible?

The view query I plan to create for the people table is:

CREATE VIEW tng_people_line_2 AS 
SELECT *
FROM `tng_people` 
WHERE branch <> ‘Line 2’; 

My goal is to block visibility to the other branches while not having to maintain duplicate data sets via separate trees. I'm trying to figure out which method will be more work in the long run. Managing separate trees or managing database views and where they pop up in the processing. 

Thanks so much for your elegant idea. 

Clelia

[GOGGS]

Maybe I misunderstood - if you simply want to control visibility by branch, that's already built in to TNG. When you are setting up a user, near the bottom there is the option to grant selected permissions for that person to all trees and  branches or "Restrict the above rights to the following:" and with the latter you can choose a tree and then a branch.

Does that make sense?

 

GOGGS

[Clelia]

Maybe I misunderstand how branches work. If I have one tree set up with branches, I thought that everyone could see everything and that extended permissions were granted to the branch. When I test the 1 tree/multiple branch method, the test user assigned to “line 2” branch can still see everything in “line 1” also. Maybe I have it set up wrong?

[tngrlkrz]

Unfortunately, it appears the use of branches cannot be used to simply say "User A only sees people in branch 1, User B can only sees people in branch 2".  Instead it only seems it is to apply user rights to viewing of people in the user's assigned branch, not the viewing outside the branch.

Ron

 

[Ken Roy]

Branch assignment can only be use to protect users marked as Living or Private from being viewed by users who are not assigned that branch label.  

In other words users assigned the branch A label can view persons marked Living or Private that are part of branch A but cannot view information on users who are assigned the branch B label or any other branch label.

If a person is not marked Living or Private then they are viewable by all users regardless of what branch label they might be part of.

 

[tngrlkrz]

1 hour ago, Ken Roy said:

marked Living or Private that are part of branch A but cannot view information on users who are assigned the branch B label or any other branch label.

A clarification to your statement:  "marked Living or Private that are part of branch A but cannot view Living  or Private information on persons who are assigned the branch B label or any other branch label."   If logon is not required, any user can see whatever an anonymous user can see.  

Even if logon is required, there is no way to prevent users assigned branch A to not see persons outside their assigned branch.  Darrin indicates the *only* way is to require logon and have multiple trees.  The restriction for visibility is by tree only, not by tree and branch.  

[Clelia]

Thank you for the clarification. I decided to go with a totally separate folder and installation on the same site. Thanks for all the help.

Clelia