Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: Current with Oracle backend

Project highlights: Stable Version: 1.6.1, Development Version: 1.7.6

current
Discussion topic

Back to topic list

Re: Current with Oracle backend

Reply

Author Pauline Middelink <middelink at polyware dot nl>
Full name Pauline Middelink <middelink at polyware dot 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
Attachments

« Previous message in topic | 2 of 6 | Next message in topic »

Messages

Show all messages in topic

Re: Current with Oracle backend theslack Jack Neely 2006-09-06 06:39:39 PDT
     Re: Current with Oracle backend Pauline Middelink <middelink at polyware dot nl> Pauline Middelink <middelink at polyware dot nl> 2006-09-06 08:05:31 PDT
     Re: A bit confused theslack Jack Neely 2006-09-07 19:01:05 PDT
         Re: A bit confused Jared Greenwald <greenwaldjared at gmail dot com> Jared Greenwald <greenwaldjared at gmail dot com> 2006-09-07 20:49:52 PDT
     Re: Current with Oracle backend jpportz Jeremy Portzer 2006-09-06 07:35:26 PDT
         Re: Current with Oracle backend jpportz Jeremy Portzer 2006-09-12 18:11:07 PDT
Messages per page: