Generate Squential Numbers?

T

Terry

Hi,

I am creating an online form to collect info. A perl script will be
executed once the form is submitted and the perl script will generate an
email message.

I am wondering if it is possible to create a unique number for each
email message it creates in the perl script. Preferably, the number
will be in sequence like 100, 101, 102, ...

My guess is that I have to create a variable that will remember the last
number generated. Is it possible to do so?

Thanks in advance!

Terry
 
J

Julia De Silva

I am creating an online form to collect info. A perl script will be
executed once the form is submitted and the perl script will generate an
email message.

I am wondering if it is possible to create a unique number for each
email message it creates in the perl script. Preferably, the number
will be in sequence like 100, 101, 102, ...

My guess is that I have to create a variable that will remember the last
number generated. Is it possible to do so?
Lots of possibilities here,
i.e store value in separate file, rather like a hit counter script.
Use the time as a key so long as you are never likely to get 2 calls in the
same second.
Put the info into a database using an autoincremental key.

Better still don't try to reinvent the wheel - use a 3rd party script with
all the bugs, security risks and other stuff already fixed.

J
 
A

A. Sinan Unur

Use the time as a key so long as you are never likely to get 2 calls
in the same second.

'never likely' is not a meaningful statement. Something is either possible
or not possible. If you cannot rule out the possibility, the fact that the
probability might be small is not important.
Put the info into a database using an autoincremental key.

This is probably preferable to all the other methods.

However, should the OP prefer for a hit counter style script:

http://www.perl.com/pub/a/2002/01/23/cgi.html

Follow the link to nms.

Sinan
 
T

Terry

Lots of possibilities here,
i.e store value in separate file, rather like a hit counter script.

Thanks for the response! Can you point a few example scripts on how
this is done? I am new to programming and new to perl too.

Terry
 
A

A. Sinan Unur

Thanks for the response! Can you point a few example scripts on how
this is done? I am new to programming and new to perl too.

I ask again: What have you tried so far? By the way, have you read the
posting guidelines for this group?

Maybe you have forgotten to look in the FAQ list before posting. The FAQ
and other documentation are available both on your computer and online.

Hint: Look in perlfaq5 for file locking.
 
A

Andrew Hamm

Terry said:
Thanks for the response! Can you point a few example scripts on how
this is done? I am new to programming and new to perl too.

You sound like you need the number to be persistent across different
executions of the script?

People commonly use modules like Data::Dumper (spelling and correct choice
not tested ;-) to export values, or just write it to a file and re-read
it. Most solutions are quite straight-forward and similar to any solution
you might make in any language.

I made a simple module that implements a persistent value in a little text
file. Efficiency is not great but it's workable for low volumes of
activity. I don't think the module is sufficiently interesting to submit
to CPAN, but here's the module file Persist.pm:


use strict;
use warnings;

package Persist;

use Fcntl;
use Carp;


sub TIESCALAR {
my $class = shift;
my $filename = shift;

my $self = { };

local *FD;

sysopen FD, $filename, O_RDWR | O_CREAT | O_SYNC
or croak "cannot open $filename: $!";

$self->{fd} = *FD{IO};
my $value = <FD>;
chomp $value if defined $value;
$self->{value} = $value;

bless $self, $class;
} # TIESCALAR


sub STORE {
my $self = shift;
my $value = shift;

$self->{value} = $value;

local *FD = $self->{fd};
seek FD, 0, 0;

print FD "$value\n";
truncate FD, tell FD;

return $value;
} # STORE


sub FETCH {
return $_[0]->{value};
} # FETCH

1;

__END__

This module (when I show you how to use it) will keep your variable stored
in a file, but it will not be 100% reliable if multiple instances of the
same script will use it in parallel. If your problem includes many scripts
running simultaneously you need an entirely different and more robust
solution. Do not trust my solution to keep your numbers unique in that
case!

You need to put this module file in a suitable place. If you maintain a
private library directory and know how to point to it, that's the go. Or
you can store it in the same directory as the script and access it in a
flexible way that doesn't demand hard-coded paths in your script. But
comfortably accessing this module is really another question with a few
possible answers that you might already know...

To use the module:

....... STUFF TO LOCATE THE MODULE ....
use Persist;
.....
my $serial = 0;
my $filename = "integer.txt";
tie $serial, 'Persist', $filename;

Now you may treat $serial as an ordinary variable and whenever you assign
to it, it will be re-written to the file. Clearly not very efficient for
huge number of allocations in rapid succession.....

eg

my $nextnum = ++$serial;

and away you go. When the script terminates the file will be closed
automatically perl.
 
A

A. Sinan Unur

You sound like you need the number to be persistent across different
executions of the script?

Yes, indeed. That's why he would be best served by reading the FAQ (you
might want to check that document as well).
People commonly use modules like Data::Dumper (spelling and correct
choice not tested ;-) to export values, or just write it to a file and
re-read it.

You need to make sure there is no chance more than one invocation of the
script accessing the file at the same time.
This module (when I show you how to use it) will keep your variable
stored in a file, but it will not be 100% reliable if multiple
instances of the same script will use it in parallel. If your problem
includes many scripts running simultaneously you need an entirely
different and more robust solution. Do not trust my solution to keep
your numbers unique in that case!

Exactly, the OP is talking about a CGI script.

I would have preferred the OP to try something on his own first. After
all, that is more conducive to learning. But now that the cat is out of the
bag, here is one way to do it. This is clearly different than the FAQ
method in that I am not locking the file I am writing to but rather a file
that just exists as a sentinel.

You will probably need to create the count and count.lock files from the
command line with the appropriate permissions before the script will run
successfully.

#! /usr/bin/perl

use strict;
use warnings;

use Fcntl qw':flock :seek';

my $count = update(
lock_file => '/path/to/count.lock',
count_file => '/path/to/count',
);

print <<OUTPUT;
Content-type: text/html

<html>
<head>
<title>Count = $count</title>
</head>
<body>
<p>
The new count is: <big><strong>$count</strong></big>.
</p>
</body>
</html>
OUTPUT

sub update {
my %args = @_;

my $lock_file = $args{lock_file};
my $count_file = $args{count_file};

open my $LOCK_FILE, '<', $lock_file
or die "Cannot open $lock_file: $!";

flock $LOCK_FILE, LOCK_EX
or die "Cannot lock $lock_file: $!";

my $count;

{
open my $COUNT_FILE, '<', $count_file
or die "Cannot open $count_file: $!";

$count = <$COUNT_FILE>;
{
no warnings;
$count += 1;
}

seek $COUNT_FILE, SEEK_SET, 0
or die "Cannot seek to the start of $count_file: $!";

print $COUNT_FILE "$count\n"
or die "Cannot write new count to $count_file: $!";

close $COUNT_FILE
or die "Cannot close $count_file: $!";
}

close $LOCK_FILE
or die "Cannot close $lock_file: $!";

return $count;
}

__END__
 
A

Andrew Hamm

A. Sinan Unur said:
Yes, indeed. That's why he would be best served by reading the FAQ
(you might want to check that document as well).

Not really. Persistence in a number of situations and solutions is not
something i struggle with. I selected a basic answer because I thought
that Terry needed something simple to get started. A core part of my work
is dealing with massively multi-user OLTP systems so even the Perl
solutions are a bit tiddly-wink compared to a full transactional system.
Exactly, the OP is talking about a CGI script.

Paying attention to that fact is important - point conceded
I would have preferred the OP to try something on his own first. After
all, that is more conducive to learning. But now that the cat is out
of the bag

That's an interesting point of view that is common around here. For what
it's worth, I'm a local guru in my company for the programmers on a few
languages, tools and products, and I have found over the years that
concrete examples to follow generally leads to quicker understanding.
Thinking abstractly and nutting out a problem for the fun of it is one
thing, but especially in my company it's also important to get the
programmers moving forward achieving deadlines and understanding new ideas
through experience is also important.

Don't underestimate the value of hands-on experience either. I think
there's room for keeping the cat in the bag and letting it out.
Schroedinger would agree I'm sure. I will give a newsgroup poster (and a
co-worker) the benefit of the doubt if they don't appear to be lazy and
stupid and proud of it.

Hope you don't think I'm trying to lecture you. Just having a pleasant
conversation about the nature of learning and putting my viewpoint.
 
A

Andrew Hamm

A. Sinan Unur said:
'never likely' is not a meaningful statement. Something is either
possible or not possible. If you cannot rule out the possibility, the
fact that the probability might be small is not important.

Yes indeed. "Unlikely" is the death-knell of any
multi-user/multi-processing system. It leads to occasional conficts which
are some of the worst bugs to fix and the only evidence is a few corrupt
records amongst millions.
 
A

A. Sinan Unur

Hope you don't think I'm trying to lecture you. Just having a pleasant
conversation about the nature of learning and putting my viewpoint.

And that's the way I take comments here.

However, I submit to you that dealing with co-workers (and students in my
case, although I don't teach programming) is different than dealing with
posters to a UseNet group.

The value of this group to me is the fact that I learn by reading about
specific problems and solutions. If it becomes a place where people just
post vague problem descriptions and expect answers, I, along with people
who are much more qualified than myself, would really have no incentive to
hang around anymore.

I suspect there are probably better solutions to (what I surmise to be) the
OP's problem but since he/she has not spent enough effort actually
formulating some of the parameters, we won't really know.

Anyway ...

Sinan
 
A

Andrew Hamm

A. Sinan Unur said:
If it becomes a place where
people just post vague problem descriptions and expect answers, I,
along with people who are much more qualified than myself, would
really have no incentive to hang around anymore.

yeah - could happen for sure. Maybe the volume of traffic is too large for
people to notice the easy questions. Still, even a vague ng question is
often much clearer than a dodgy 30 page spec from an unqualified "business
analyst".

Now I must go wash my mind out and say a few prayers to the Gods of
"customerisalwaysrightahh" aka Hari Kissass
 
A

A. Sinan Unur

Now I must go wash my mind out and say a few prayers to the Gods of
"customerisalwaysrightahh" aka Hari Kissass

:)))

I had never heard that one before.

Sinan.
 
J

Josef Moellers

Andrew said:
Yes indeed. "Unlikely" is the death-knell of any
multi-user/multi-processing system. It leads to occasional conficts which
are some of the worst bugs to fix and the only evidence is a few corrupt
records amongst millions.

Isn't "unlikely" a synonym for "will not happen during tests or qa, but
will happen when the customer does important work"?
 
A

Andrew Hamm

Josef said:
Isn't "unlikely" a synonym for "will not happen during tests or qa,
but will happen when the customer does important work"?

It can also mean it will happen several times in testing, and then it will
cause delay for weeks because it never recurs on the development machine.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,054
Latest member
TrimKetoBoost

Latest Threads

Top