Generate Squential Numbers?

Discussion in 'Perl Misc' started by Terry, Dec 6, 2004.

  1. Terry

    Terry Guest

    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
    Terry, Dec 6, 2004
    #1
    1. Advertising

  2. Terry <> wrote in
    news::

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


    What have you tried?

    Sinan
    A. Sinan Unur, Dec 6, 2004
    #2
    1. Advertising

  3. > 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
    Julia De Silva, Dec 6, 2004
    #3
  4. "Julia De Silva" <> wrote in
    news:gN0td.118925$:

    >> 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?
    >>


    > 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
    A. Sinan Unur, Dec 6, 2004
    #4
  5. Terry

    Terry Guest


    > 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
    Terry, Dec 7, 2004
    #5
  6. Terry <> wrote in
    news::

    >
    >> 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.


    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. Sinan Unur
    d
    (remove '.invalid' and reverse each component for email address)
    A. Sinan Unur, Dec 7, 2004
    #6
  7. Terry

    Andrew Hamm Guest

    Terry wrote:
    >> 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.


    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.
    Andrew Hamm, Dec 8, 2004
    #7
  8. "Andrew Hamm" <> wrote in
    news::

    > Terry wrote:
    >>> 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.

    >
    > 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. Sinan Unur, Dec 8, 2004
    #8
  9. Terry

    Andrew Hamm Guest

    A. Sinan Unur wrote:
    >
    > 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.
    Andrew Hamm, Dec 8, 2004
    #9
  10. Terry

    Andrew Hamm Guest

    A. Sinan Unur wrote:
    >
    >> 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.


    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.
    Andrew Hamm, Dec 8, 2004
    #10
  11. "Andrew Hamm" <> wrote in
    news::

    > 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. Sinan Unur, Dec 8, 2004
    #11
  12. Terry

    Andrew Hamm Guest

    A. Sinan Unur wrote:
    >
    > 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
    Andrew Hamm, Dec 8, 2004
    #12
  13. "Andrew Hamm" <> wrote in
    news::

    > 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.
    A. Sinan Unur, Dec 8, 2004
    #13
  14. Andrew Hamm wrote:
    > A. Sinan Unur wrote:
    >
    >>>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.

    >
    >
    > 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"?
    --
    Josef Möllers (Pinguinpfleger bei FSC)
    If failure had no penalty success would not be a prize
    -- T. Pratchett
    Josef Moellers, Dec 8, 2004
    #14
  15. Terry

    Andrew Hamm Guest

    Josef Moellers wrote:
    >
    > 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.
    Andrew Hamm, Dec 9, 2004
    #15
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Weng Tianxiang
    Replies:
    5
    Views:
    1,298
    Christophe
    Feb 16, 2006
  2. Peter R
    Replies:
    2
    Views:
    7,399
    Alex Vinokur
    May 11, 2004
  3. Levi Campbell
    Replies:
    20
    Views:
    719
    Levi Campbell
    Nov 28, 2005
  4. Replies:
    3
    Views:
    396
    red floyd
    Apr 7, 2006
  5. Harlan Messinger
    Replies:
    2
    Views:
    2,278
    John Bell
    Mar 28, 2010
Loading...

Share This Page