After update to 1.8.1.801 Error trying to view Repositories in server configuartion

Continua CI Bugs
1

When trying to access Administration/Repositories

"An unexpected error occurred: More than one row with the given identifier was found: 32, for class: Continua.Modules.Builds.Repositories.RepositoryData"

And 'No repositories were found.'

I’ve got snapshots so I can revert to the previous version easily, wondering if there’s something I can do to fix this easily?

2

Hi Brenden

This is a very strange error, since that table is part of a 1 to 1 mapping (looking like a bug in nhibernate) and there is a unique constraint on the id field.

Stop the Continua CI server service, then have a look at the builds_repositorydata table in the database for rows with the id 32.

If you are using the bundled postgresql, you can use c:\Program Files\VSoft Technologies\ContinuaCI\Server\PostgreSQL\bin\pgAdmin3.exe - the db will be localhost, port 9001, username and pwd you can find in :

c:\Program Files\VSoft Technologies\ContinuaCI\Server\Continua.Server.Service.exe.config

If there are duplicate rows, then delete the one with the oldest lastchecked time.

While you are there, check for other duplicate rows.

3

Thanks. I had to revert the snapshot for now.

We’re using the bundled Postgresql, the installation appeared to backup and restore the DB (at least it said it was ;-). I should be able to take another run at this over the upcoming weekend.

4

Just had a moment to check, ran:

select id, count(id) from builds_repositorydata
group by id
having count(id) > 1
order by id

Returned 2 rows, ID 32 and 20. I’ll delete the oldest prior to next attempt.

5

Hi Brenden,

You may need to use the ctid to delete rows with duplicate primary keys. Run the following query to get the ctid values:

SELECT ctid, * FROM builds_repositorydata  
WHERE id = 20 or id = 32

Then use the ctid to delete a specific row:

DELETE FROM builds_repositorydata  
WHERE ctid = '(0,1)'

Can you also check that there is indeed a primary key on the builds_repositorydata table under constraints? It should be called pk_builds_repositorydata. If not, you can recreate it after deleting the duplicates using the following SQL query:

ALTER TABLE public.builds_repositorydata
  ADD CONSTRAINT pk_builds_repositorydata PRIMARY KEY(id);
  
 We recommend that you reindex the table after removing the duplicates by running:

REINDEX TABLE builds_repositorydata


6

I had the same problem, and discovered that there was no primary key on this table:

public.builds_repositorydata

Removing the oldest of the duplicates and creating a primary key solved the problem.

7

That’s very odd, I went though our db migration code and that pk was there from day one, it’s also there on all our installs here, and on a fresh install I just did. We’ll see if we can add a check for it and add it if it’s missing.

8

The PK constraint is there.

I added a temporary unique index on ID + lastchecked so I could easily delete the duplicates, then dropped the temporary index I had created.

We’re upgraded to 1.8.1.801 and operating properly at this time.