Re: cooperation between existing Perl cgi programs and Minivend possible?

[Philip Tsai <tsailipu@yahoo.com>]

 Hi Mike,

 Thanks for the reply.  Please see the inserted message
seeking for a clarification regaring MV internal DB file
access/locking.

--- mikeh@minivend.com wrote:
> ******    message to minivend-users from
> mikeh@minivend.com     ******
> 
> Quoting Philip Tsai (tsailipu@yahoo.com):
> > 
> > Hello all,
> > 
> > I am a new user of minivend and just start to
> learn
> > the intricacy of MV. To start, I have read through
> the MV documentation
> > and searched through the mail archive
> > for a topic that I think, to many users coming
> from the popular Perl
> > cgi scripting community, should probably be an
> FAQ.  However, I can't
> > quite find discussions or
> > documentation about this:
> > 
> >   Is it possible for existing Perl cgi scripts to
> > cooperate/interact with Minivend ?  For instance,
> say if I already have
> > a Perl script that implements stage-by-stage
> form-filling, -verifying
> > and -confirmation tasks (a popular, basic task for
> a cgi script, I
> > hope), will it be able to update/modify/share
> > a product/order/user DB with MV ?
> > 
> > By reading MV doc., I know one can always
> re-implement such
> > form-filling/verifying task using MV
> > templates and tags.  However, there are some
> merits to a standalone,
> > working Perl cgi scripts (for one thing,
> > form-filling/verifying/confirmation can be
> implemented in one cgi
> > script, whereas if one is to do such
> stage-by-stage task, one has to
> > write separate MV pages (if my understanding of MV
> is correct so far)).
> >  That's why I wonder whether in general it's
> possible for external Perl
> > scripts to cooperate with MV at least w.r.t. the
> use of common DB
> > files.  One possible issue that arises is the
> possible DB file-locking
> > between Perl and MV, i.e. can a Perl script simply
> lock a MV DB file
> > (say, *.asc/gdbm) while reading/updating that file
> without running into
> > a race condition with MV ?
> > 
> > To a new user coming from Perl cgi-scripts, the
> above seems to be a
> > natural question to ask, and if so, perhaps we can
> make it an FAQ ? :)
> > 
> 
> Here is where DBI comes in. As long as you use a SQL
> database, you
> should be fine there.

 So I take it as it means that as long as both the external Perl and MV
are using a SQL database, one doesn't have to worry about
sharing/locking the DB, since the SQL environment will take care of
that automatically....
 
> 
> MiniVend's internal databases would require locking
> (or access by using
> its modules). It does honor file locks on the ASCII
> files so you could directly
> access those if you wanted without too much fear of
> corrupting the databases.

  This is where my question comes in.  If the external Perl scripts
just want to use MV's internal DB file (.asc/.gdbm), then either the
Perl script can simply lock the .asc/.gdbm (using Perl's own file
locking mechanism) when updating it, or the Perl script can "use" the
MV modules and call MV's internal file locking function to help lock
the .asc/.gbdm.  Is this interpretation correct ?  In such cases, does
one need to lock both .asc AND .gdbm, or I take it as you mean that one
can simply lock the .asc file and MV will honor this lock even if MV is
updating/accessing the corresponding .gdbm file ?  If this is the case,
I suppose MV, before accessing/updating the corresponding .gbdm file,
always checks for locks on the .asc file first (?).  

 Finally, would you suggest that one can still use external Perl script
to cooperate with MV w.r.t. the DB usage, or that one should simply
transform all existing scripts to MV templates/pages lest that MV's
implementation on this issue changes in the future ?

 Thanks a lot!

 Philip






__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com