When building a search and choosing the “LinkedTo” link
type all tickets are returned. This is 3.4.HEAD. Anyone else
seee the same problem?
-Todd
When building a search and choosing the “LinkedTo” link
type all tickets are returned. This is 3.4.HEAD. Anyone else
seee the same problem?
It’d help to know what the TicketSQL query it’s generating is and
whether that query fails when it’s run in the test suite
When building a search and choosing the “LinkedTo” link
type all tickets are returned. This is 3.4.HEAD. Anyone else
seee the same problem?It’d help to know what the TicketSQL query it’s generating is and
whether that query fails when it’s run in the test suite
Of course. 
Ticket SQL:
LinkedTo = ‘2’
MySQL Query:
SELECT count(main.id) FROM Tickets main WHERE ((main.EffectiveId = main.id)) AND ((main.Status != ‘deleted’)) AND ((main.Type = ‘ticket’))
In contrast
Ticket SQL:
RefersTo = ‘2’
MySQL Query:
SELECT COUNT(DISTINCT main.id) FROM Tickets main , Links Links_1 WHERE ((main.EffectiveId = main.id)) AND ((main.Status != ‘deleted’)) AND ((main.Type = ‘ticket’)) AND ( ( (Links_1.Type = ‘RefersTo’)AND(Links_1.LocalTarget = ‘2’)AND(main.id = Links_1.LocalBase) ) )
When building a search and choosing the “LinkedTo” link
type all tickets are returned. This is 3.4.HEAD. Anyone else
seee the same problem?It’d help to know what the TicketSQL query it’s generating is and
whether that query fails when it’s run in the test suiteOf course.
Ticket SQL:
LinkedTo = ‘2’
MySQL Query:
SELECT count(main.id) FROM Tickets main WHERE ((main.EffectiveId = main.id)) AND ((main.Status != ‘deleted’)) AND ((main.Type = ‘ticket’))
In contrast
Ticket SQL:
RefersTo = ‘2’
MySQL Query:
SELECT COUNT(DISTINCT main.id) FROM Tickets main , Links Links_1 WHERE ((main.EffectiveId = main.id)) AND ((main.Status != ‘deleted’)) AND ((main.Type = ‘ticket’)) AND ( ( (Links_1.Type = ‘RefersTo’)AND(Links_1.LocalTarget = ‘2’)AND(main.id = Links_1.LocalBase) ) )
And of course this one isn’t right either if you have RTFM installed
and are looking for links to other tickets and not links to articles.
MySQL Query:
SELECT COUNT(DISTINCT main.id) FROM Tickets main , Links Links_1 WHERE ((main.EffectiveId = main.id)) AND ((main.Status != ‘deleted’)) AND ((main.Type = ‘ticket’)) AND ( ( (Links_1.Type = ‘RefersTo’)AND(Links_1.LocalTarget = ‘2’)AND(main.id = Links_1.LocalBase) ) )
And of course this one isn’t right either if you have RTFM installed
and are looking for links to other tickets and not links to articles.
Why? Only Tickets should be using LocalBase and LocalTarget.
MySQL Query:
SELECT COUNT(DISTINCT main.id) FROM Tickets main , Links Links_1 WHERE ((main.EffectiveId = main.id)) AND ((main.Status != ‘deleted’)) AND ((main.Type = ‘ticket’)) AND ( ( (Links_1.Type = ‘RefersTo’)AND(Links_1.LocalTarget = ‘2’)AND(main.id = Links_1.LocalBase) ) )
And of course this one isn’t right either if you have RTFM installed
and are looking for links to other tickets and not links to articles.Why? Only Tickets should be using LocalBase and LocalTarget.
I didn’t know that, and apparently neither does RTFM.
That looks like a bug.
MySQL Query:
SELECT COUNT(DISTINCT main.id) FROM Tickets main , Links Links_1 WHERE ((main.EffectiveId = main.id)) AND ((main.Status != ‘deleted’)) AND ((main.Type = ‘ticket’)) AND ( ( (Links_1.Type = ‘RefersTo’)AND(Links_1.LocalTarget = ‘2’)AND(main.id = Links_1.LocalBase) ) )
And of course this one isn’t right either if you have RTFM installed
and are looking for links to other tickets and not links to articles.Why? Only Tickets should be using LocalBase and LocalTarget.
I didn’t know that, and apparently neither does RTFM.
That looks like a bug.
I really don’t understand the need for LocalTarget/LocalBase. Is
it just an optimization? Target/Base should be all we need
for searching…
MySQL Query:
SELECT COUNT(DISTINCT main.id) FROM Tickets main , Links Links_1 WHERE ((main.EffectiveId = main.id)) AND ((main.Status != ‘deleted’)) AND ((main.Type = ‘ticket’)) AND ( ( (Links_1.Type = ‘RefersTo’)AND(Links_1.LocalTarget = ‘2’)AND(main.id = Links_1.LocalBase) ) )
And of course this one isn’t right either if you have RTFM installed
and are looking for links to other tickets and not links to articles.Why? Only Tickets should be using LocalBase and LocalTarget.
I didn’t know that, and apparently neither does RTFM.
mysql> select * from Links where LocalTarget=‘2’;
| 11495 | fsck.com-rt://gedasusa.com/ticket/13653 | fsck.com-rtfm://gedasusa.com/article/2 | RefersTo | 2 | 13653 | 158 | 2005-04-07 19:05:16 | 158 | 2005-04-07 19:05:16 |
| 11911 | fsck.com-rt://gedasusa.com/ticket/14068 | fsck.com-rtfm://gedasusa.com/article/2 | RefersTo | 2 | 14068 | 158 | 2005-04-14 15:11:40 | 158 | 2005-04-14 15:11:40 |
| 16512 | fsck.com-rt://gedasusa.com/ticket/18587 | fsck.com-rtfm://gedasusa.com/article/2 | RefersTo | 2 | 18587 | 158 | 2005-06-23 14:34:16 | 158 | 2005-06-23 14:34:16 |
| 16513 | fsck.com-rt://gedasusa.com/ticket/18787 | fsck.com-rtfm://gedasusa.com/article/2 | RefersTo | 2 | 18787 | 158 | 2005-06-23 14:34:38 | 158 | 2005-06-23 14:34:38 |
| 16514 | fsck.com-rt://gedasusa.com/ticket/18924 | fsck.com-rtfm://gedasusa.com/article/2 | RefersTo | 2 | 18924 | 158 | 2005-06-23 14:41:12 | 158 | 2005-06-23 14:41:12 |
That looks like a bug.
I really don’t understand the need for LocalTarget/LocalBase. Is
it just an optimization? Target/Base should be all we need
for searching…
Ok. Show me how to join the tickets table to the links table.
That looks like a bug.
I really don’t understand the need for LocalTarget/LocalBase. Is
it just an optimization? Target/Base should be all we need
for searching…Ok. Show me how to join the tickets table to the links table.
I think I see the problem. Does that mean you can’t join
rtfm articles to the links table?
Maybe we need to store the URI for each ticket in the Tickets
table for the join? Maybe we wouldn’t need to do that if we
could make it a computed field. I don’t know if SB would
support that…
-Todd
That looks like a bug.
I really don’t understand the need for LocalTarget/LocalBase. Is
it just an optimization? Target/Base should be all we need
for searching…Ok. Show me how to join the tickets table to the links table.
I think I see the problem. Does that mean you can’t join
rtfm articles to the links table?
Nope. it means we need to store the Article’s URI in the Articles table
(which is what we do). It was something I wasn’t comfortable doing with
the “primary” object in RT, but for future changes, benchmarking can
sway me. (But joining on ints will alaways be faster than joining on a
long string)
That looks like a bug.
I really don’t understand the need for LocalTarget/LocalBase. Is
it just an optimization? Target/Base should be all we need
for searching…Ok. Show me how to join the tickets table to the links table.
I think I see the problem. Does that mean you can’t join
rtfm articles to the links table?Nope. it means we need to store the Article’s URI in the Articles table
(which is what we do). It was something I wasn’t comfortable doing with
the “primary” object in RT, but for future changes, benchmarking can
sway me. (But joining on ints will alaways be faster than joining on a
long string)
So at this time you want a patch for RT:
:Create() that
makes sure LocalBase and LocalTarget are only set for Tickets
and NULL otherwise?
What about the old records? Should we have an upgrade script to
fixup the Links?
Damn, now I have to go add a URI field to Assets…
-Todd