[Nitro] temporary database structures
william.full.moon at gmail.com
Thu Jun 15 21:16:49 EDT 2006
Yes, I think there are 'prosaic' solutions for your query. As usual it
depends on your application's specific needs.
My reading here is that you have a potential-customer who will enter data on
more than one screen/page/dialogue/panel? At least two screens, and at
least one is sent back to the host. No data to the host, nothing is going
to be in the database. Right?
>> I'm wondering if anyone may have suggestions, experiences, or best
>> to share for dealing with this kind of incomplete data.
There are different ways to view this scenario. The BUSINESS process case
is that ALL your transactions should be on a journal and periodically posted
to the general accounts. That is to say in this example even your completed
screens posted and the user clicks the [BUY] button ought to be in a
transaction journal, trading journal, day book, front counter receipts.
Choose your jargon they all mean the trading data for the "day".
That strange way of doing things is a basic for double-entry accounting.
You WANT that in a cash business to ensure that the money in the till or the
cash banked balances against what you think you sold.
So if this is a live program for a paying customer, I'd be speaking with
your financial accountant and asking them what their requirements are on
this? What are the local regulations you need to comply with via a vie
* That is not a digression. It means that in the real world there's a good
70% to 80% chance you have to do end-of-day processing anyway and could
legitimately dump incomplete data-entry from experimenting customers. :-D
A common way is to save the intermediate data with the USER's browser as
Cookie data. This is fine as long as it isn't huge. Order entry
information is not usually big-big. So screen one you save the data in a
cookie, and screen two append new data to the cookie. On the last page you
send all the fields to the host with your GET or POST call.
* Your host becomes really simple since all transactions are complete ones
that only need verification and processing. It makes your user interface
implementation independent from the back-end business processing too. (Also
a good thing).
Another way is to use something like AJAX or still use GET/PUT to send data
to the host for a local in-memory "store". I saw something along this line
in the [nitro] replies. Keep it/them in memory like the "cookie" idea --
this one works on a host. The cookie version works on the client.
If the server breaks, or link falls over nothing is lost. I query garbage
collection. If an object has an active reference, it should stay "live".
You would still need to do server-side clean-up of in-memory resources
Some server architectures (PSP, ASP,...) have client session concepts. If
not you can implement something for yourself. A browser side script to say
_still here_ can "ping" you with a GET or a AJAX packet. A so called
The big issue with server-side contexts like this is how busy is you site?
One or my friend's first web based customer site froze the nice big Solaris
server because the marketing people completely underestimated the demand.
My lesson from his unlucky time is set a MAX-CLIENT const, and you can
re-use the session data on a LEAST-RECENTLY-USED basis. Effectively "aging"
the in memory server side processes.
* Your main host processing remains simple since all transactions are
(still) complete ones. In this scenario the 'cache' is on the server.
There is a finite limit on memory needed. You have a "server capacity"
concept (MAX USERS) that ensures reasonable server usage and your
"neighbours" will like you because your application is not a HOG. User
interface implementation independent from the back-end business processing
Please note -- none of these options have save stuff to the tables, except
the day-journal process. Actually my thought is you will need something
that does the audit stuff as good as a day journal anyway.
Sometimes you want the customer to come back and be "remembered" so if I was
through a complex set of screens, the stuff I did three days ago is
pre-filled. Here you want the data on the disk somewhere. Who says it
needs to be in your db? It can be in a table that is wiped
"Drop intermediate_table; Create intermediate_table;"
Each time the server begins or on some regular basis, like once a week. IF
that is attractive, I suggest using user-side cookies, since they data can
be "secure" on the users PC and not on your server. One good hacker gets
everyone on a server. On the user's workstation, on hacker gets one or two
>From here in we'd get variations on the above client - server - something in
between -- Mix and match the implementation with the application
"encrypt them" with some simple key. Add some design notes for the
lecturer to explain why this is good for your specific solution and send
cold-beer to me.
From: nitro-general-bounces at rubyforge.org
[mailto:nitro-general-bounces at rubyforge.org] On Behalf Of Bill Kelly
Sent: Thursday, 15 June 2006 05:05
To: General discussion about Nitro
Subject: [Nitro] temporary database structures
I'm writing a fairly standard shopping app, with customers adding items to a
cart, entering shipping and/or billing addresses, etc.
Of course, someone browsing the store may add stuff to their cart, maybe
fill in some forms, but ultimately never complete their order.
These abandoned, partially-completed orders will remain in the database,
unless I perform some periodic housekeeping sweep to clean out old
I'm wondering if anyone may have suggestions, experiences, or best practices
to share for dealing with this kind of incomplete data.
For now, I'll probably just let it accumulate, and write some housecleaning
script when it becomes needed.
But maybe there are better approaches? If it were easy to have two
different database connections with Og, I might have one database holding
temporary orders, and only store completed orders in the main database.
Thanks for your thoughts,
Nitro-general mailing list
Nitro-general at rubyforge.org
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.8.4/364 - Release Date: 14-Jun-2006
More information about the Nitro-general