View Issue Details

IDProjectCategoryView StatusLast Update
08156Development [All Projects] Otherpublic2019-09-23 12:20
Reportersammousa Assigned Toc_schmitz  
PrioritynormalSeverityminor 
Status confirmedResolutionopen 
Product Version 
Target Version2.1Fixed in Version 
Summary08156: Survey_links table.
Description

The Survey_links table has, amongst others, the following columns:

  • participant_id
  • survey_id
  • token_id

The token table has, amongst others, the following columns:

  • token_id
  • participant_id
    [implied: survey_id]

Shouldnt we be able to remove the token_id column from the survey_links table?

TagsNo tags attached.

Activities

c_schmitz

c_schmitz

2013-10-11 12:36

administrator   ~26722

Reminder sent to: jcleeland

I agree. Jason, do you see that too, or are there any reasons behind it?

jcleeland

jcleeland

2013-10-12 12:37

reporter   ~26756

The token_id is a leftover, since before the CPDB we used that to connect to the tokens table. I would be cautious about removing it, since there are probably links, and as far as I recall, there is no requirement to use the CPDB for every survey - can't you still run a survey with just it's own stand-alone tokens table?

c_schmitz

c_schmitz

2013-10-12 20:46

administrator   ~26759

Jason, you might have misunderstood: The question was if to remove the token_id column from the "survey_links" table?

mdekker

mdekker

2013-10-15 11:16

reporter   ~26799

Don't use cpdb myself, but when token table is removed or changed there should still be a reference. So make sure to use a left join to the token table and handle the missing data correctly.

jcleeland

jcleeland

2013-10-15 11:37

reporter   ~26800

I can see how it is redundant, but if you were just doing a join between the CPDB and the tokens table for a survey, then without it you'll need to also join to the responses table, so it may be false economy to remove it.

c_schmitz

c_schmitz

2013-10-15 11:45

administrator   ~26801

I am sorry, I don't understand: Why would I also need to join to the responses table?

c_schmitz

c_schmitz

2013-10-21 14:24

administrator   ~26872

If you take another link at the survey_links table you can see that the fields
date_created
date_invited
date_completed

are redundant, too. If we remove these fields we would know in what token tables the participant would be - but to get specifics we would need to lookup each entry in the particular tokens table. I think this only matters if the participant is part of a huge number of surveys - and only if someone really opens up the participants grid and looks at the details of a participant.
Also currently them same participant cannot have several token entries in the same survey (so there is no problem either).

Comments?

jcleeland

jcleeland

2013-10-22 05:09

reporter   ~26893

At design time I was hoping we could allow multiple participants in the same survey, but that was for another time. I see no need to remove the field, it has low overheads, and it has possible future use.

The other fields you mention were also added so that there would be specific information about when the participant was joined / invited to a particular survey. It is supposed to be a reference to the action of joining a participant to a survey. It should relieve some database overheads for commonly required data in the CPDB screens.

If you want to drop them and gather the information by doing joins with other tables, then so be it - but I think given the size of the tables that may be joined, you'd just be adding overhead to frequent calls.

c_schmitz

c_schmitz

2013-10-22 08:43

administrator   ~26894

Last edited: 2013-10-29 21:46

View 2 revisions

But afaik they are not frequently called. Just once when I open the detail view for a user in the CPDB grid? I also see no other uses in the source code.

What's bothering is the redundant data - it is easy to forget to update it when you update the main tokens.

sammousa

sammousa

2013-10-30 15:39

reporter   ~27039

Let's just put this in 2.10 where the database will get reworked anyway.

Issue History

Date Modified Username Field Change
2013-09-13 10:32 sammousa New Issue
2013-10-11 12:31 c_schmitz Assigned To => c_schmitz
2013-10-11 12:31 c_schmitz Status new => assigned
2013-10-11 12:36 c_schmitz Note Added: 26722
2013-10-12 12:37 jcleeland Note Added: 26756
2013-10-12 20:46 c_schmitz Note Added: 26759
2013-10-15 11:16 mdekker Note Added: 26799
2013-10-15 11:37 jcleeland Note Added: 26800
2013-10-15 11:45 c_schmitz Note Added: 26801
2013-10-21 14:24 c_schmitz Note Added: 26872
2013-10-22 05:09 jcleeland Note Added: 26893
2013-10-22 08:43 c_schmitz Note Added: 26894
2013-10-29 21:46 c_schmitz Note Edited: 26894 View Revisions
2013-10-30 15:39 sammousa Note Added: 27039
2013-10-30 15:39 sammousa Status assigned => acknowledged
2013-10-30 15:39 sammousa Target Version 2.05 RC => 2.1
2013-10-30 15:45 c_schmitz Project Bug reports => Development
2019-09-23 12:20 c_schmitz Status acknowledged => confirmed