App-SD

 view release on metacpan or  search on metacpan

lib/App/SD/Replica/rt.pm  view on Meta::CPAN

sub foreign_username { return shift->rt_username(@_) }

sub get_txn_list_by_date {
    my $self   = shift;
    my $ticket = shift;
    my @txns   = map {
        my $txn_created_dt = App::SD::Util::string_to_datetime( $_->created );
        unless ($txn_created_dt) {
            die "Couldn't parse '" . $_->created . "' as a timestamp";
        }
        my $txn_created = $txn_created_dt->epoch;

        return { id => $_->id, creator => $_->creator, created => $txn_created }
        }

        sort { $b->id <=> $a->id }
        RT::Client::REST::Ticket->new( rt => $self->rt, id => $ticket )->transactions->get_iterator->();
    return @txns;
}

=head2 uuid

Return the replica's UUID

=cut

sub _uuid_url {
    my $self = shift;
    return join( '/', $self->remote_url, $self->query );

}

sub remote_uri_path_for_id {
    my $self = shift;
    my $id = shift;
    return "/ticket/".$id;
}

=head1 NOTES ON PUSH

If the remote storage (RT) can not represent a whole changeset along with the prophet changeset uuid, then we need to 
create a seperate locally(?) stored map of:
    remote-subchangeset-identifier to changeset uuid.
    remote id to prophet record uuid


For each sync of the same remote source (RT), we need a unique prophet database domain.

if clkao syncs from RT, jesse can sync with clkao but not with RT directly with the same database.


Push to rt algorithm

apply a single changeset that's part of the push:
    - for each record in that changeset:
        - pull the record's txn list from the server
        - for each txn we don't know we've already seen, look at it
            - if it is from the changeset we just pushed, then
                store the id of the new transaction and originating uuid in the push-ticket store.
                    - does that let us specify individual txns? or is it a high-water mark?
             - if it is _not_ from the changeset we just pushed, then 
                do we just ignore it?
                how do we mark an out-of-order transaction as not-pulled?



Changesets we want to push from SD to RT and how they map


what do we do with cfs rt doesn't know about?



SD::Source::RT->recode_ticket



=cut

__PACKAGE__->meta->make_immutable;
no Any::Moose;

1;



( run in 2.170 seconds using v1.01-cache-2.11-cpan-39bf76dae61 )