On Tue, Jul 20, 2010 at 8:34 PM, Simon Slavin <slav...@bigfraud.org> wrote:

>
> On 21 Jul 2010, at 12:42am, Sam Carleton wrote:
>
> > There are two equally
> > important requires, one is to connect to the second "EventDB", the other
> is
> > that the system admin can change the EventDB at any time.
>
> You mean change the contents of that file, or change which file is
> nominated as the EventDB file ?
>

the later, at one point in time EventDB might be D:\Events\Hopeville
Classic\event.sqlite and later it will be D:\Events\Main Street
Classic\event.sqlite

True that it doesn't change often, but the admin can change it at will.


>
> > The second
> > requirement means that connection can be attached to a database called
> > EventDB, but it is the wrong (old) DB.
>
> What signifies the 'right' EventDB ?  Are you creating at least two
> different files (a right one and a wrong one) and giving them the same
> filename in the same directory ?  If they're different files they should
> have different filenames.


Some of your questions are answered above.  Ultimately the concept is an
"event" is like a word processor document or spreadsheet document.  The
event.sqlite file is only one physical file which makes up the whole of an
"event".  All the contents of the folder (Hopeville Classic or Main Street
Classic) in which the event.sqlite resides makes up the whole of the
"event".

The system admin can, at will, go in and "load" a new "event", aka point the
system to a new folder or simply create a whole new event.


> It seems to me that you either need to attach an EventDB file only as long
> as a command is trying to use it.  If you can't do that you need a way to
> tell your application that the EventsDB file it's currently connected to is
> out of date, and it's time to go find a new EventDB file.
>

First off, please remember that I am doing in a web server that is using
connection pooling.  This is a very important fact...

My issue with only attaching to the EventDB for only as long as a command is
trying to use it is:  The EventDB is used a LOT, a WHOLE lot.  If I attach
and drop between each little call, then within one HTTP request I might
attach and drop 3 to 8 times.  What is the cost associated with
attaching/dropping a database?  Since it involves attaching to a physical
file, I am assuming it is a bit high.

As far as telling my application when the EventDB file is out of date:  It
would be pretty easy for me to add a timestamp to the EventDB variable that
is in the primary database, but...  Once I get a connection from the
connection pool, how do I know the age of that connection to know if the
EventDB it is attached to is the new one or the old one?  Is there some
connection age or timestamp I could use?  I am guessing not, which is why I
am using the PRAGMA database_list to determine if the EventDB is attached
and if so, find the physical path to the EventDB file to see if it matches
with the current system settings.

I am VERY open to any ideas that will help me improve the performance and
design, I simply am not seeing any.  I know for a fact that I am using both
the Web Server and the database is a none classical ways, which makes for
all sorts of funny requirements.  The whole objective of my system is to
allow none technical folks setup and manage a web server on an intranet and
easily back things up without knowing a darn thing about web servers or
databases!  So far folks love the system, but the hoops I have to jump
through to make it all work seamlessly, wow!

Sam
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to