Re: [Openledger-developer] The correct way to db?

[Klavs K. <kl...@vs...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

on 04-03-2005 19:52 Tony Fraser wrote:
[SNIP]

|
| Only when there's no harm in doing so. GL::post_transaction()
| doesn't use AutoCommit and only commits once it is finished all its
| statements.
|
| The transaction support in SL is actually quite robust IMHO. I
| think that is a big part of the reason why it is so popular and
| "Just Works". When is the last time you heard anything on
| sql-ledger-users about data corruption that wasn't caused by
| hardware failure or PostgreSQL misconfiguration?

post_transaction does not look right to me -but ofcourse he does not
call the db directly - but uses some object of his own. but no matter.

|> I'd suggest using commit/rollback - and (it was news to me) using
|> ? in the prepare statements, to replace values, which is then
|> given in the execute($var1,$var2,...) call when executing.
|
| Definitely, SL is a bit of a mixed bag on the placeholder front.
| There is newer code (audit trail, and POS for instance) that uses
| placeholders and there is older (like the stuff in GL.pm) that
| doesn't.
|
| While we're on the topic of placeholders, my preference is for
| positional placeholders. ie.
|
| INSERT INTO blah (foo, bar, baz) VALUES (:1, :2, :3)

Cool - I didn't know you could to that too. do you give the number to
execute, or is it just the order, that decides their number?
[SNIP]

|> I see SL (ie. Dieter) is generating it's own unique ID and then
|> replacing on that :(
|>
|> I'd prefer using sequences like this:
|>
|> ~    # first generate a unique id for this table ~    id =
|> dbh.select_one("SELECT nextval('"id"').first
|>
|> ~    # now insert row ~    dbh.do("INSERT INTO test (id, name,
|> phone) VALUES (?,?,?)", id, "foo", "42")
|>
|> The thing is, that currently the SL db has 3 sequences, id,
|> invoiceid and orderitemsid - and I'm not a 100% sure that I can
|> use id for the gl table?
|
|
| invoiceid and orderitemsid are strictly for audit trails. As far as
| I'm aware they are _NEVER_ used for referential integrity. Also
| they are only ever used in the table that their name corresponds
| to.

hmm. Do I need to do some audit-trail stuff in my post_transaction
function(perhaps SL does it - and It's just hidden in some function or
the form)?

|> If I can use it - then isn't that the correct way to do it?
|
|
| I'm not really a DB guy but the way SL does it is very common in my
|  experience and I believe it is considered to be "the RDBMS
| independent way".

I bet it is - but I thought we agreed on not wanting to make it DB
independant, to make use of some of postgresql's features?

But I'll just do it the way SL does - then I don't have to change the
sql statements :)

I'm soon ready to check it into CVS :)
busy saturday and sunday with other things - but I'll finish up in the
evenings next week, and check it - and start using it :)

- --
Regards,
Klavs Klavsen, GSEC - kl...@vs... - http://www.vsen.dk
PGP: 7E063C62/2873 188C 968E 600D D8F8  B8DA 3D3A 0B79 7E06 3C62

"Those who do not understand Unix are condemned to reinvent it, poorly."
~  --Henry Spencer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFCKLkCPToLeX4GPGIRAn66AKCQb0vtxPwBRqpI3voBB4boexWlNwCbBSxa
LoaOdttYzQZv+bIHqizxLAg=
=Ri7W
-----END PGP SIGNATURE-----