help with conditional please

[perlescent]

I am sorting through a list of filenames within a dir.

Opening the filenames I can read the bookingReference in a hash.

if ($accommodations{$Keyword}) {
$booked = 1;
last;
} # end if

if ($booked) {
&booked;
} else {
&vacancies;
}

The difficulty is that both instances will be true, most often. I need to & booked if no vacancies and &vacancies if there is even just one vacancy. But how do I evaluate the hash. is that even the correct term?

perlescent.

 

[perlescent]

got it.

while ( my $Line = <DAT> ) {
last if ( index($Line, ':') == -1 );
chomp $Line;
my ( $Keyword, $Value ) = split /:/, $Line, 2; #splits the line at the first : ignoring any others
if ($Keyword eq "BookingReference") {
$bookingReference = $Value;
chop $bookingReference;
}
}

if (!$bookingReference) {
$countVacancies++;
}

} # end if $specificRoomRequested = $filename
} # end foreach @rooms

#print "countV's = $countVacancies\n";
if ($countVacancies > 0) {
&enterDetails;
} else{
&booked;
}


P

 

[stevexff]

chomp is safer than chop, especially if the last line of a file is missing its (CR)LF.

Also, assuming this is another part of the program in your previous post, am I correct in assuming that you get one file created each time a room is booked? It has the look of an application that has grown organically over time.

If so, it might be better to analyse the contents of all the files and come up with a data structure that would support reading all of them into a hash of hashes or similar (or, perish the thought, a database...). If you did this in another subroutine, you could put all the unpleasant splits, joins, and regexps that are needed to parse the data all in one place. Then once you had a nice clean data structure in memory, it would be much easier to iterate over it anytime you needed to summarise or extract the information to support a new feature you want to add.

 

[perlescent]

Thank you Steve.

Yes, you are right, I do create a separate file for each booked room. In fact, it's a separate file for each night, for each room. Few details, (checkInDate, checkOutDate, bookingReference), since the majority of the occupants data is held in a guest's details text file.

When you suggest reading in all the files data, do you mean read every file into one huuuge hash? So far, I have been openeing and reading in, just those that I need the data from because I thought that would be more effcient. However, I am not as experienced in perl as I want/need to be so any advice is welcome.

Bazz

 

[stevexff]

Depends what you mean by huge. How many rooms in the hotel? How many years ahead do you need to book?

 

[perlescent]

well, there could be 500 rooms in the hotel and the capability to book up to three years in advance. thats 365/366 days, x 3 years x 500 rooms = 547500 files approx. That's just for one accommodation provider. There could be 50 of them in total.

bazz

 

[KevinADC]

you should really be using a database, or at least an indexed text file that holds all the booking dates in one master file so you can do quick searches for reserved/not-reserved rooms. I really think you need to rethink your strategy.

 

[perlescent]

Yeh, will do that.

Thank you.

Bazz

 

[stevexff]

So this is not a hobby system, it's a full-on commercial application, and you need to treat it as such. A file system with 25m files is a maintenance nightmare, and would not be classed as 'fit for purpose' if you got sued over it. A database with 25m records, on the other hand, is much more manageable. Search and lookup performance will be way better because of the indexing, and updates will be more secure because of transactional support and atomicity. If nothing else, day-to-day housekeeping management of backups, logging, and deletion/archive of records will be much simpler and safer.

So have a look at a relational database, maybe MySQL or PostgreSQL. If you don't know anything about relational DBs, buy a book.

Then have a serious think about Providers, Hotels, Rooms, RoomTypes, Customers, and Bookings as a starter for ten. Before you even consider getting near a keyboard and start cutting any code...

 

[perlescent]

Thanks Steve.

Indexing/speed was the one thing I was aware of as a benefit with a Db. What I am actually trying to do is build a working model, so that I can then show it to a programmer, who may build me a MySQL 'version'. I reckon it would be easier to understand if seen 'working'.

I know what my customers need and I am trying to build in all the things they require. Then I'll need a programmer to do the MySQL for it.

Is there anywhere you'd recommend I look for such a programmer? I don't know if I can use this forum for that.

bazz

 

[stevexff]

You mean it may be easier to sell to your customer if seen 'working' As an architect, I often get 'designs' from business analysts rather than requirements. Tell your programmer what requirements the system needs to meet, not how it should be achieved, with maybe a few guidelines like 'must be Perl', 'must use a database', and 'must have three nines availability'. If they are any good at their job at all, they should be able to build your prototype for you.

You may get some takers on this forum - there are certainly some bona fide Perl gurus hanging out here - I guess it depends where in the world you are.

 

[perlescent]

Well, I am in the UK and, nope, I am not trying to make it easier to sell. I am intent on building a high-quality system and it's easier to keep track of what I want it to do, from my own perspective, if I have something of a model.

I appreciate your advice and don't want to sound like I disagree but, it is at the point now, where it does seem to work from the admin side and maintenance of the files seems straightforward. I just have to finish the front end, specifically, where bookings are imputted. That is almost done.

Before you made your suggestion, I was concerned that it might not be the most efficient from a processing point of view. And that is why I was thinking of a MySQL version.

I don't have a programmer to build it for me so I need to keep looking. I could (I suppose), learn MySQL but more cost effective would be finding someone who is good at it and who builds it so that when adding a new business, I have only to fill out a config type file for the system automatically to create their res system.

bazz

 

[stevexff]

It wasn't intended as a rant, so apologies if it came across that way. I was just concerned that you might be making a rod for your own back - with the amount of data you will be holding (and the train wreck waiting to happen if you lost any of it) it would be a good idea to design in non-functional things like recoverability, backup strategy, and data security right from the start. From this perspective a database will be much safer, cleaner, and faster than thousands of tiny files.

Also, as you already have a mostly-working prototype, you might want to think about separation of concerns. It's generally condsidered a Bad Idea to have your data access code all wrapped up in your presentation code. If you split your data access out into a subroutine that returns a structure (list, hash, or combination of both), then the presentation code can just work with the structure. If you then need to change the data access (say to switch to MySQL), then you only have to worry about changing the data access subroutine. Separating out the presentation makes it simpler to re-skin the site, too.

Breaking it up like this makes it easier to get your head around what the code is doing, as it is in more manageable chunks. It also makes chasing down bugs simpler.

Steve

 

[perlescent]

Thanks Steve. I didn't take it as a rant.

I understand what you're saying about the separation issue. I shall look at that now.
One further question; if I may...

The sub which I have run to read in data from some files, builds a hash (%rooms) and an array @vacancies. having done that, the script runs another sub, (&enterDetails where there is a form for the guest's info.

having filled out that form and then by running another sub, to save their data to a flat file (/cgi-bin/guestDetails/filename), I need to use the @vacancies.

How do I pass the value of @vacancies from one sub to another without re-running the first sub? does 'return @vacancies;' do that or, should I just make the @vacancies a global variable?


bazz

 

[stevexff]

You can maybe pass it as a reference e.g. return \@vacancies; but I'm not sure what happens if you create a 'my @vacancies' inside a sub and return a reference to it. Scoping rules kind of imply that it will disappear when the sub exits. You might have to suck it and see. Well, actually, as I've got time, I'll suck it and see...

use strict;
use warnings;

my $ref = scopeCheck();

print join("\n", @$ref);

sub scopeCheck {
	my @array = ('does', 'it', 'survive');
	return \@array;
}

OK, so it works.

The other alternative is to make them global as you suggested. But now that we know the reference method works, it's better to use that.

 

[perlescent]

Thank you Steve.

I did know that the return would work but what I didn't know was whether it would cause the sub to be re-run whenever the @array was called in the next, or later, subroutines.

And it's good that I don't need to make it global.

bazz

 

[1DMF]

bazz,

Why do you beleive you need a programmer to create the SQL version.

You seem more than capable to me, SQL is not a different language it's a data storage system.

You will easily be able to pick it up if you can write PERL.

All my apps used to use flat text files for the DB, I converted it over to a SQL platform, as easy as pie, with a little help from Tek-Tips.

And the way I have done this means it will work with any backend DB, I have the same code running with MS SQL on one system and MS Access for another, the code doesn't change once you have it using SQL commands for data extraction.

I'd concider making it SQL yourself, it'll give you an extra feather in your cap also


"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[perlescent]

Well, I wouldn't exactly call myself a PERL wizard And I would rather stick with perl as the language though my ISP only offers a phpMyAdmin, which I guess would only enable me to admin, the SQL Db, using PHP.

Not, yet, having looked into it, it probably seems more daunting than it really is.

bazz

 

[1DMF]

is your webhost ActiveState PERL on a windows box?

if so you can use MS Access as the DB backend.

But using phpMyAdmin doesn't stop you from being able to write all your code in PERL.

I do all my code in PERL, if I want to use the SQL db i have to use some admin thing which is why I don't , I use MS access, I have easy control over my data that way.

But it depends on how many records you're likely to have, if it's millions then MS access isn't up to the job, but if it's thousands, then there is no problem.

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[perlescent]

My ISP is running Apache with phpMyAdmin and MySQL.

That's good to know that phpMyAdmin doesn't stop me using perl. I know that perl and MySQL would work together but I thought, in my ignorance that, it may need another software package.

I nearly have this as a working model now. Once there, I shall have to push myself, to start learning MySQL.

bazz