Looks like I am a bit puzzled by frames linking, for which I had a lot of expectations.
In particular, I expected the link to establish a more direct way to utilize the information contained in a different dataset, literally a view in the SQL sense.
Consider the following
Quite clearly, my expectation is that after establishing a link between the two frames one can utilize the linked variables naturally in all commands run in the higher level frame. Leaving aside the matters of names collisions (which is not my case) I literally wanted:
1) to save quite a lot of memory by not repeating the same (household) information twice (as in my case for every one of the pair of household members), and keep the data normalized (in the relational db sense).
2) to be able to refer the other frame's content naturally by the name of the variable, without having to use the frval() to access values, without having to remember which variable comes from where, and without having to copy their values to the current frame, (since as I understand its applicability is limited); ideally ALL the variables from the other frame (default merge's behavior);
3) to have the values from the other frame to propagate to the current frame when they change there, but frget seems to create a snapshot (more reasonable name would have been frcopy then) of the variable, and subsequent changes in the source don't affect the frame where it was frgotten.
4) to have #3 work both ways: so that if the value is changed in the current frame, it does change in the subordinate frame (the dictionary frame). I understand that a consequence of that would be that when I change, say X[5] that may simultaneously change X[13], X[29] and X[41] (if they happened to have the same id as record in obs 5).
Perhaps, there is a different command that could achieve this?
If not are there any plans to have the frames taken so far?
Since all access to data ultimately goes through two functions (a la st_data(i,k), st_sdata(i,k)) I believe it is just a matter of getting it from the other frame implicitly under the hood, without having the user to do it manually with frval().
Naturally I understand this may come with some limitations, such as having to have unique variable names, fit the total width/number of variables limits, etc.
In particular, I expected the link to establish a more direct way to utilize the information contained in a different dataset, literally a view in the SQL sense.
Consider the following
Code:
clear all // Households frame create hh frame hh: input hhid urban 1 1 2 1 3 0 4 0 end // Persons (reside in households) input hhid age wage 1 39 8 1 42 7 2 37 9 2 56 12 3 37 4 3 64 6 4 29 5 4 42 6 end frlink m:1 hhid, frame(hh) display frval(hh, urban) capture noisily regress wage age urban // this fails generate z=frval(hh, urban) // this works capture noisily regress wage age frval(hh, urban) // but this also fails describe frget urban, from(hh) summarize urban regress wage age urban // this works frame hh: summarize urban frame hh: replace urban=0 frlink rebuild hh summarize urban frame hh: summarize urban regress wage age urban // this works though expected to give different estimation results now, after the source has changed
Quite clearly, my expectation is that after establishing a link between the two frames one can utilize the linked variables naturally in all commands run in the higher level frame. Leaving aside the matters of names collisions (which is not my case) I literally wanted:
1) to save quite a lot of memory by not repeating the same (household) information twice (as in my case for every one of the pair of household members), and keep the data normalized (in the relational db sense).
2) to be able to refer the other frame's content naturally by the name of the variable, without having to use the frval() to access values, without having to remember which variable comes from where, and without having to copy their values to the current frame, (since as I understand its applicability is limited); ideally ALL the variables from the other frame (default merge's behavior);
3) to have the values from the other frame to propagate to the current frame when they change there, but frget seems to create a snapshot (more reasonable name would have been frcopy then) of the variable, and subsequent changes in the source don't affect the frame where it was frgotten.
4) to have #3 work both ways: so that if the value is changed in the current frame, it does change in the subordinate frame (the dictionary frame). I understand that a consequence of that would be that when I change, say X[5] that may simultaneously change X[13], X[29] and X[41] (if they happened to have the same id as record in obs 5).
Perhaps, there is a different command that could achieve this?
If not are there any plans to have the frames taken so far?
Since all access to data ultimately goes through two functions (a la st_data(i,k), st_sdata(i,k)) I believe it is just a matter of getting it from the other frame implicitly under the hood, without having the user to do it manually with frval().
Naturally I understand this may come with some limitations, such as having to have unique variable names, fit the total width/number of variables limits, etc.
