Bug #105552 for DBIx-Admin-BackupRestore: restore is crashing if table is empty.

Mon Jun 29 08:20:52 2015 me [...] marcosg.com - Ticket created

Subject:	restore is crashing if table is empty.
Date:	Mon, 29 Jun 2015 22:20:36 +1000
To:	bug-DBIx-Admin-BackupRestore [...] rt.cpan.org
From:	Marcos Georgopoulos <me [...] marcosg.com>

Hi, Firstly thank you for your hard work with this module. I have an issue where restore_in_order is failing if a table has no rows. I'm not a very good coder but it appears that if there are no rows then you go to the next record in your code below; $self -> process_table('Restore', $candidate_table); # Warning: At this point, if the input file has no data for a table, # $$record{'row'} will be undef, so don't access @{$$record{'row'} }. next if (! $$record{'row'}); If we are already at this point in the code haven't we already found the matching resultset for the tablename specified? So wouldn't it be efficient to break out of the loop here? I am finding what is happening is after it finds the matching resultset for my table with no rows it then goes on through processing the other records and seems to eventually crash calling get_record at the top of the infinite for loop. I hope this makes sense. Once again thank you for your help.

Tue Jun 30 22:37:28 2015 ron [...] savage.net.au - Correspondence added

Subject:	Re: [rt.cpan.org #105552] restore is crashing if table is empty.
Date:	Wed, 01 Jul 2015 12:41:22 +1000
To:	bug-DBIx-Admin-BackupRestore [...] rt.cpan.org
From:	Ron Savage <ron [...] savage.net.au>

Hi Marcos Thanx for the report. This whole ticket raises the question of how much I should re-write this module using more modern code. I have not decided on that yet, but many things would then be changed. Perhaps I should just fix this issue. More below. On 29/06/15 22:20, Marcos Georgopoulos via RT wrote: Show quoted text

> Mon Jun 29 08:20:52 2015: Request 105552 was acted upon. > Transaction: Ticket created by me@marcosg.com > Queue: DBIx-Admin-BackupRestore > Subject: restore is crashing if table is empty. > Broken in: (no value) > Severity: (no value) > Owner: Nobody > Requestors: me@marcosg.com > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=105552 > > > > Hi, > > Firstly thank you for your hard work with this module. > > I have an issue where restore_in_order is failing if a table has no rows. > > I'm not a very good coder but it appears that if there are no rows then you > go to the next record in your code below; > > $self -> process_table('Restore', $candidate_table); > > # Warning: At this point, if the input file has no data for a table, > # $$record{'row'} will be undef, so don't access @{$$record{'row'} }. > > next if (! $$record{'row'}); > > > If we are already at this point in the code haven't we already found the > matching resultset for the tablename specified? So wouldn't it be efficient > to break out of the loop here?

The docs for XML::Records say it returns (undef, undef). I need to test with an empty table, which I assume I did not ever do. But this statement at the top of the loop: last if (! $record); should handle that. Show quoted text

> I am finding what is happening is after it finds the matching resultset for > my table with no rows it then goes on through processing the other records > and seems to eventually crash calling get_record at the top of the infinite > for loop.

The exact error message would help :-). Show quoted text

> I hope this makes sense.

Yep. Show quoted text

> Once again thank you for your help.

Nice to know someone is using this module. -- Ron Savage - savage.net.au

Tue Jun 30 22:37:28 2015 The RT System itself - Status changed from 'new' to 'open'

Tue Jun 30 23:52:47 2015 me [...] marcosg.com - Correspondence added

Subject:	Re: [rt.cpan.org #105552] restore is crashing if table is empty.
Date:	Wed, 1 Jul 2015 13:52:27 +1000
To:	bug-DBIx-Admin-BackupRestore [...] rt.cpan.org
From:	Marcos Georgopoulos <me [...] marcosg.com>

Hi Ron, Thank you for getting back to me so quickly. Sorry I wasn't as descriptive as I could have been. The program doesn't actually crash, it just appears to never end. It seems that at some point a call to get_record doesn't return. I did some basic troubleshooting and it seems to be in the get token code within that library. I'm not sure if its getting caught in a loop OR if its just taking a really long time. My DB file generated by your program is about 500MB. I left it running for about 3 hours and the call to get_record still hadn't finished. On Wed, Jul 1, 2015 at 12:37 PM, ron@savage.net.au via RT < bug-DBIx-Admin-BackupRestore@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=105552 > > > Hi Marcos > > Thanx for the report. > > This whole ticket raises the question of how much I should re-write this > module using more modern code. I have not decided on that yet, but many > things would then be changed. Perhaps I should just fix this issue. > > More below. > > On 29/06/15 22:20, Marcos Georgopoulos via RT wrote:

> > Mon Jun 29 08:20:52 2015: Request 105552 was acted upon. > > Transaction: Ticket created by me@marcosg.com > > Queue: DBIx-Admin-BackupRestore > > Subject: restore is crashing if table is empty. > > Broken in: (no value) > > Severity: (no value) > > Owner: Nobody > > Requestors: me@marcosg.com > > Status: new > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=105552 > > > > > > > Hi, > > > > Firstly thank you for your hard work with this module. > > > > I have an issue where restore_in_order is failing if a table has no rows. > > > > I'm not a very good coder but it appears that if there are no rows then

> you

> > go to the next record in your code below; > > > > $self -> process_table('Restore', $candidate_table); > > > > # Warning: At this point, if the input file has no data for a table, > > # $$record{'row'} will be undef, so don't access @{$$record{'row'} }. > > > > next if (! $$record{'row'}); > > > > > > If we are already at this point in the code haven't we already found the > > matching resultset for the tablename specified? So wouldn't it be

> efficient

> > to break out of the loop here?

> > The docs for XML::Records say it returns (undef, undef). I need to test > with an empty table, which I assume I did not ever do. > > But this statement at the top of the loop: > > last if (! $record); > > should handle that. >

> > I am finding what is happening is after it finds the matching resultset

> for

> > my table with no rows it then goes on through processing the other

> records

> > and seems to eventually crash calling get_record at the top of the

> infinite

> > for loop.

> > The exact error message would help :-). >

> > I hope this makes sense.

> > Yep. >

> > Once again thank you for your help.

> > Nice to know someone is using this module. > > -- > Ron Savage - savage.net.au > >

Wed Jul 01 00:18:45 2015 ron [...] savage.net.au - Correspondence added

Subject:	Re: [rt.cpan.org #105552] restore is crashing if table is empty.
Date:	Wed, 01 Jul 2015 14:22:39 +1000
To:	bug-DBIx-Admin-BackupRestore [...] rt.cpan.org
From:	Ron Savage <ron [...] savage.net.au>

Hi Marcos OK. Thanx. Every bit of info helps. On 01/07/15 13:52, Marcos Georgopoulos via RT wrote: Show quoted text

> Queue: DBIx-Admin-BackupRestore > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=105552 > > > Hi Ron, > > Thank you for getting back to me so quickly. > > Sorry I wasn't as descriptive as I could have been. The program doesn't > actually crash, it just appears to never end. > > It seems that at some point a call to get_record doesn't return. I did some > basic troubleshooting and it seems to be in the get token code within that > library. I'm not sure if its getting caught in a loop OR if its just taking > a really long time. > > My DB file generated by your program is about 500MB. I left it running for > about 3 hours and the call to get_record still hadn't finished. > > > > On Wed, Jul 1, 2015 at 12:37 PM, ron@savage.net.au via RT < > bug-DBIx-Admin-BackupRestore@rt.cpan.org> wrote: >

>> <URL: https://rt.cpan.org/Ticket/Display.html?id=105552 > >> >> Hi Marcos >> >> Thanx for the report. >> >> This whole ticket raises the question of how much I should re-write this >> module using more modern code. I have not decided on that yet, but many >> things would then be changed. Perhaps I should just fix this issue. >> >> More below. >> >> On 29/06/15 22:20, Marcos Georgopoulos via RT wrote:

>>> Mon Jun 29 08:20:52 2015: Request 105552 was acted upon. >>> Transaction: Ticket created by me@marcosg.com >>> Queue: DBIx-Admin-BackupRestore >>> Subject: restore is crashing if table is empty. >>> Broken in: (no value) >>> Severity: (no value) >>> Owner: Nobody >>> Requestors: me@marcosg.com >>> Status: new >>> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=105552 > >>> >>> >>> Hi, >>> >>> Firstly thank you for your hard work with this module. >>> >>> I have an issue where restore_in_order is failing if a table has no rows. >>> >>> I'm not a very good coder but it appears that if there are no rows then

>> you

>>> go to the next record in your code below; >>> >>> $self -> process_table('Restore', $candidate_table); >>> >>> # Warning: At this point, if the input file has no data for a table, >>> # $$record{'row'} will be undef, so don't access @{$$record{'row'} }. >>> >>> next if (! $$record{'row'}); >>> >>> >>> If we are already at this point in the code haven't we already found the >>> matching resultset for the tablename specified? So wouldn't it be

>> efficient

>>> to break out of the loop here?

>> >> The docs for XML::Records say it returns (undef, undef). I need to test >> with an empty table, which I assume I did not ever do. >> >> But this statement at the top of the loop: >> >> last if (! $record); >> >> should handle that. >>

>>> I am finding what is happening is after it finds the matching resultset

>> for

>>> my table with no rows it then goes on through processing the other

>> records

>>> and seems to eventually crash calling get_record at the top of the

>> infinite

>>> for loop.

>> >> The exact error message would help :-). >>

>>> I hope this makes sense.

>> >> Yep. >>

>>> Once again thank you for your help.

>> >> Nice to know someone is using this module. >> >> -- >> Ron Savage - savage.net.au >> >>

-- Ron Savage - savage.net.au