[rt-users] RT to go? Dependency graphs?

[Johan Ihren]

Marc Hedlund <marc at precipice.org> writes:

> On 15 Apr 2002, Johan Ihren wrote:
> >    So what I would like to do is run RT on top of a replicated MySQL
> >    db with slave replicas in our laptops. 
> [...]
> >    Is this idea a strong indication of someone either finally going
> >    bonkers or at least trying to fit a square nail into a triangular
> >    hole? 
> 
> Yes, to both questions.  That's craaazy.  Or at least way too much work
> for the reward.  

Thank you, sir. I will not deny that you are most probably right here ;-)

I *realise* this, and I want to make that clear. Also, I am not
experienced with real databases. So I have to ask: way too much work
to *whom*? To me to make it work? To the master db keeping update
logs? To the client (my laptop) trying to stay in sync?

> How about ssh tunnelling to the RT host and making updates that way; and
> putting together a comma-separated table extractor to let people with no
> net connection at all view their current work in excel or the like?  You
> get all the read-only + remote benefits in this scheme, for much less
> work.

Ssh tunneling: not relevant, if I have net access, then I have net
access. This is for *not* having net access.

Excel: well, we are not a Windoze persons, we're Unix people. I have
lots of respect for Excel, which is a fine tool running under the
wrong OS (not a religious point, merely an observation of the
cumbersomness of dualbooting etc).

But *why* does it have to be more trouble to set up automatic
replication than to muck around with selective extraction into a
different tool? To me it seems like replication is something you get
right once and then it (hopefully) just works, while all kinds of
extraction scripts will just have to be kept forever in sync with RT
changes and will even then only provide a bleak copy of the original
RT environment.

* I can easily spare a few GB of disk in the laptop if needed (not
  that I think we will get there anytime soon), so space is not the
  issue. Nor is bandwidth when I have connectivity.

* MySQL, as I understand (I have not tried this) supports replication
  where the slave both changes addresses and just tells the master
  from where to respool the log. In fact, the master doesn't even
  track the slaves, it just spews out data at clients that provide the
  right credentials regardless of where they are. This is actually the
  main point to me.

* I would have exactly the same interface to the data locally
  (i.e. the same hierchy of webpages accessible through my browser
  instead of switching to a different tool).

> If you really want what you're asking for, I'd recommend looking at
> disconnected rowsets in Java or C# as a way of getting a database
> extract, mucking around with it on a disconnected client, and
> updating the source database when connectivity is restored.  Still a
> lot of work, but more likely to perform than complete replication.

I have a lot of respect for the technical problems with replication.
But at the same time one interesting characteristic of a trouble
ticket system is that although we may hug along many thousands of
tickets the "active set" is usually a rather small subset. I.e. most
of the data is static, which very much simplifies replication, given
reasnoably frequent updates (typicall lagging a few days behind, not
weeks or months).

So, you're probably correct. There are people who claim that my main
purpose in life seems to be having craaazy ideas, and this may be one
of them.

But to become convinced I would like to hear why replication wouldn't
work in this scenario.

Regards,

Johan