Login | Register
My pages Projects Community openCollabNet
Project highlights: Stable Version: 1.6.1, Development Version: 1.7.6

current
Reply to message

* = Required fields
* Subject
* Body
Attachments
Send reply to
Topic
Author (directly in email)
Please type the letters in the image above.

Original message

Author Pauline Middelink <middelink@polyware.nl>
Full name Pauline Middelink <middelink@polyware.nl>
Date 2006-09-06 08:05:31 PDT
Message On Wed, 06 Sep 2006 around 09:39:39 -0400, Jack Neely wrote:
> The mailing lists please? Mostly because folks out here know more SQL than
> I.
>
> That entire code path is done in one commit so that if we encounter a
> file system error (out of space, permissions, whatever) we can
> rollback to the last known good state. Otherwise, the database is
> possibly corrupt. So however the database code works, that needs to
> be the final result.
>
> My understanding of transactions (which may be flawed) is that the
> thread that is modifying the database via a transaction will be the
> only thread to *see* those changes until it is committed. Otherwise,
> how does one insert foregn keys into other tables?

I too have a hard time understanding this. The intermediate commits
play havoc with the intended result as Jack describe above. For
all intent and purpose the process doing the transaction should have
a clean view of all inserted data.

<pauze>

If what was said is true, my PACKAGE table should have duplicates when a
seach failed to turn up the requested data and so _insertPackageTable
will do a second insert. However, settingi a unique index over all fields
in PACKAGES results in no problems, thus no duplicates. (This database
has 108 machines and 9228 unique packages, so any problems would have
turned up i think.)

The only thing you must not do is run 2 scans at the same time. If
that would happen, and one of them should roll back, the other one
is in deep, deep trouble. (dangling package_id's)

Can you give more information about the database engine you are using?
I myself use mysql 4.1 with InnoDB, and I think Jack uses sqlite.

> >I'm running into some fundamental issues with the sql code that I was
> >wondering if you could shed some light on.
> >
> >When running the cadmin scan calls, the code is running through adding
> >entries to the package, rpm, dependency (etc.) tables. The problem I'm
> >seeing that that all of the updates to all of these tables seem to be
> >rolled up into a huge transaction that is going to be committed all at
> >once. This would be ok, but there are points in the path of inserting
> >data that you check for data that you just inserted. This is a problem
> >without interim commits, as the data won't always show up.
> >
> >Case and point is adding to the package table in _insertPackageTable
> >(take a look, you'll see what I mean). Another place is
> >_insertRpmTable. For me, I had to add commits after each of the insert
> >sql statements in order for me to be able to find the correct _id that I
> >just inserted.
> >
> >I understand the commit as a whole method, but I'm not sure there's any
> >way around these interim commits.

    Met vriendelijke groet,
        Pauline Middelink
--
GPG Key fingerprint = 2D5B 87A7 DDA6 0378 5DEA BD3B 9A50 B416 E2D0 C3C2
For more details look at my website http://www.polyware.​nl/~middelink