There's also DateTime::Event::Recurrence, but that seems to have no serialization/inflation.

I think that what the AM was trying to suggest was that you could indeed serialize the objects in a similar fashion as the clone/copy methods. However, looking into an object's internals is usually a brittle solution, as the internals might change across versions without being reflected in the change logs. Instead, I'd suggest serializing based on the object's API, which is less likely to change (at least until someone implements serialization natively for those objects :-) ). Here's a simple idea, just store the values from %params in whatever form you like in the database:

use DateTime::Event::Recurrence;

my %params = ( recur=>'daily', hours=>10, minutes=>30 );
my $recur = delete $params{recur};
my $event = DateTime::Event::Recurrence->$recur(%params);
# same as DT::E::Recurrence->daily( hours=>10, minutes=>30 )
[download]

There's also DateTime::Event::Recurrence, but that seems to have no serialization/inflation. Maybe I could dump the object as perl and store that in the database, but yuck.

huh?

 

sub clone {
    my $self = shift;
    my $new = $self->SUPER::clone( @_ );
    $new->set_ical( $self->get_ical );
    $new;
}

sub clone { 
    my $self = bless { %{ $_[0] } }, ref $_[0];
    $self->{set} = $_[0]->{set}->copy;
    return $self;
}
sub copy {
    my $self = shift;
    my $copy = $self->empty_set();
    ## return $copy unless ref($self);   # constructor!
    foreach my $key (keys %{$self}) {
        if ( ref( $self->{$key} ) eq 'ARRAY' ) {
            @{ $copy->{$key} } = @{ $self->{$key} };
        }
        else {
            $copy->{$key} = $self->{$key};
        }
    }
    return $copy;
}
[download]

You're saying that because "clone" works by serializing/deserializing, I could use that?

You're saying that because "clone" works by serializing/deserializing, I could use that?

huh?

I think I'm saying, its open source, so copy/paste the source and modify as required and fill in the blanks