How do I create an array to represent an empty record?

Rails
1

Here’s something that’s a snap to do in desktop database management
systems (like Paradox or Access) but I haven’t figured out how to do it
in RoR, and can’t seem to find any examples by googling, etc.

My overall goal is to create a temporary space in which to create and
process a single new record (representating a payment transaction), and
when I’m done with it post it to the payments table. Some of the field
values will be collected from the user and validated, then others will
be calculated based on the user-supplied values and other factors. I
don’t want to edit the payments table until I’m ready to post the
completed record.

In the desktop software, this would be done by creating an array based
on the payment record’s column names, using that to gather and validate
the data, then copying the array values into a new record. A single
command can copytoarray or copyfromarray a record.

I tried modelling this on the Cart example in Agile Web D. with
Rails (which stores virtual lineitem records in the shopping cart). I
was able to put a single empty record into @pmttrans, but couldn’t
figure out how to address a field in that record in order to read or
write a specific data value. The Cart example creates an @items array
within @cart. Since I don’t need multiple items, how can I just create a
simple hash of column names and values for the single record?

Or is there an even simpler way to approach this that I’m missing?

Thanks!
Shauna

2

do you mean like this (for a pointless example)?:

payment = Payment.new

payment.total = params[:total]
payment.tax = payment.total * 0.9

if payment.save
# Data is now save to database table
end

The point being that the table is only modified when you call the save
method when creating a new activeRecord object.

3

Thanks. That’s the way I first tried it, but I’m concerned about two
things. First, a transaction number is generated based on existing
records in payment. What if another user tries to post a record to the
same loan while the first user is taking their time with the first post?
Also, is the payment table actually open when you execute Payment.new?
I’d like to open it only if and when I’m ready to post.

Or are these questions not relevant to a web-based app, and I need not
worry about it?

Shauna

4

Well, I’ve been trying to mimic the existing desktop app, where the
number is presented first and then the user enters the date, selects the
transaction code from a drop-down list, and fills in a few relevant
fields which vary based on the transaction code they selected. It’s not
always a simple consecutive number, because within a pay period there
can be multiple decimalled transactions. But I’m just guessing that the
user needs to verify this number before proceeding… I’ll ask the
original developer. (Really I’d like to poll the existing users :slight_smile: )

Thanks for the help.

Shauna

5

The table is not touched until you call save (and then only if the
object validates)…

So you generate a transaction number before receiving all the
information from the user? Is this necessary? Could you give them the
transaction number after it has been accepted?

6

Hi unknown (Guest),

I know whereof you speak but the transaction number in this case is not
a unique identifier in the payments table, it’s just unique within a
particular loan. Although it’s a long shot that two different users
might possibly be entering transactions for the same loan, I just wanted
to be sure when and where I’d have to intervene if it did occur. The
numbers do need to be sequential for human reasons (so that the order in
which the transactions for a particular loan were entered is visually
obvious when data is retrieved for reports etc.).

Shauna

7

This is one of the classical breaking points of object-relational
mapping - the transaction boundary. It occurs in single user and
mutli-user paradigms equally.

If, for auditing purposes, there is a requirement that transaction
numbers be sequential, and you don’t need a transaction number until
the transaction is comitted, then generate your transaction ID at save
time within the boundaries of the database transaction.

If, for auditing purposes, there is a requirement that transaction
numbers be sequential, and you need transaction numbers early, then
make sure that you record thetransactionearly, and be prepared to
record the transaction as being canceled by user or aborted due to
technical failure.

If there is no need for keeping the transaction number sequential (not
likely), then youcan throw away unused numbers. Numbers are cheap, if
they have enough digits.