Looking at the schema diagram generated from the DOT file,
I think it might be out of date. Should the Links table
have some sort of dotted line to (Any RT::Record), or is
this just documenting the typical use case?
-Todd
Looking at the schema diagram generated from the DOT file,
I think it might be out of date. Should the Links table
have some sort of dotted line to (Any RT::Record), or is
this just documenting the typical use case?
No. Links are either tied directly to tickets or to arbitrary URIs.
Looking at the schema diagram generated from the DOT file,
I think it might be out of date. Should the Links table
have some sort of dotted line to (Any RT::Record), or is
this just documenting the typical use case?No. Links are either tied directly to tickets or to arbitrary URIs.
Am I correct in understanding that the links to arbitrary URLs
were added later, and that links directly to tickets is more
of a backwards compatability thing?
No. Links are either tied directly to tickets or to arbitrary URIs.
Am I correct in understanding that the links to arbitrary URLs
were added later, and that links directly to tickets is more
of a backwards compatability thing?
Nope. It’s a “and you can’t easily build joins between a ticket id and a
URL” thing.
No. Links are either tied directly to tickets or to arbitrary URIs.
Am I correct in understanding that the links to arbitrary URLs
were added later, and that links directly to tickets is more
of a backwards compatability thing?Nope. It’s a “and you can’t easily build joins between a ticket id and a
URL” thing.
Or between two URL things… right?
No. Links are either tied directly to tickets or to arbitrary URIs.
Am I correct in understanding that the links to arbitrary URLs
were added later, and that links directly to tickets is more
of a backwards compatability thing?Nope. It’s a “and you can’t easily build joins between a ticket id and a
URL” thing.Or between two URL things… right?
Huh? It’s easy to join on string equality. but joining a ticket id to a
URL isn’t doable. The way we’ve solved this for RTFM is to contrive the
full URI for an article and store it in the Articles table. Which
doesn’t make me really happy.
No. Links are either tied directly to tickets or to arbitrary URIs.
Am I correct in understanding that the links to arbitrary URLs
were added later, and that links directly to tickets is more
of a backwards compatability thing?Nope. It’s a “and you can’t easily build joins between a ticket id and a
URL” thing.Or between two URL things… right?
Huh? It’s easy to join on string equality. but joining a ticket id to a
URL isn’t doable. The way we’ve solved this for RTFM is to contrive the
full URI for an article and store it in the Articles table. Which
doesn’t make me really happy.
At this point I’m not sure if we are talking past each other.
What I am trying to do is understand if I am mis-using links
in Asset Tracker, where I have been successfully using Link
to define relationships between assets, as well as between
assets and tickets.
-Todd
No. Links are either tied directly to tickets or to arbitrary URIs.
Am I correct in understanding that the links to arbitrary URLs
were added later, and that links directly to tickets is more
of a backwards compatability thing?Nope. It’s a “and you can’t easily build joins between a ticket id and a
URL” thing.Or between two URL things… right?
Huh? It’s easy to join on string equality. but joining a ticket id to a
URL isn’t doable. The way we’ve solved this for RTFM is to contrive the
full URI for an article and store it in the Articles table. Which
doesn’t make me really happy.At this point I’m not sure if we are talking past each other.
What I am trying to do is understand if I am mis-using links
in Asset Tracker, where I have been successfully using Link
to define relationships between assets, as well as between
assets and tickets.
Right. that’s absolutely fine. I was talking about not being able to do
a JOIN in the database between a URI and an integer.