SQL Error for Unknown Reason

Hello!

We have run into the following issue when attempting to
republish a modified media object:
> An error occurred while processing your request:
> 
> Unable to execute SQL statement
> 
> DBD::Pg::st execute failed: ERROR:  duplicate key
violates unique constraint "pk_job__resource"
> [for Statement "
>            INSERT INTO job__resource (job__id,
resource__id)
>            VALUES (?, ?)
>        " with ParamValues: 1='244053', 2='4449']
at /usr/local/bricolage/lib/Bric/Util/DBI.pm line 1083, >
<GEN1> line 1019.
>
> Please report this error to your administrator.

I'm confused, however, because my examination of the
database reveals the following:
=> select * from job__resource where job__id='244053';
 job__id | resource__id
---------+--------------
(0 rows)

=> d job__resource
    Table "public.job__resource"
    Column    |  Type   | Modifiers
--------------+---------+-----------
 job__id      | integer | not null
 resource__id | integer | not null
Indexes:
    "pk_job__resource" PRIMARY KEY, btree
(job__id, resource__id)
    "fkx_job__job__resource" btree (job__id)
    "fkx_resource__job__resource" btree
(resource__id)
Foreign-key constraints:
    "fk_job__job__resource" FOREIGN KEY (job__id)
REFERENCES job(id) ON DELETE CASCADE
    "fk_resource__job__resource" FOREIGN KEY
(resource__id) REFERENCES resource(id) ON DELETE CASCADE

bric=> select * from job__resource where
resource__id='4449';
 job__id | resource__id
---------+--------------
  244026 |         4449
  242570 |         4449
  242526 |         4449
  232415 |         4449
  232407 |         4449
(5 rows)

I don't see how the primary key requirement is being
violated, since the new job__id is clearly unique, and there
already exist multiple entries for this resource__id.

Any thoughts?

Thanks!
Alexander




Alexander Vallens
System Administrator
Architectural Energy Corporation
http://www.archenergy.com
Voice:  303-459-7463
Fax:    303-444-4304

You have version 1.10.2?
http://marc.info/?l=bricolage-general&m=1
18224971532440&w=2

On Fri, 7 Sep 2007, Alexander Vallens wrote:
> Hello!
>
> We have run into the following issue when attempting to
republish a modified media object:
>> An error occurred while processing your request:
>>
>> Unable to execute SQL statement
>>
>> DBD::Pg::st execute failed: ERROR:  duplicate key
violates unique constraint "pk_job__resource"
>> [for Statement "
>>            INSERT INTO job__resource (job__id,
resource__id)
>>            VALUES (?, ?)
>>        " with ParamValues: 1='244053',
2='4449'] at /usr/local/bricolage/lib/Bric/Util/DBI.pm line
1083, > <GEN1> line 1019.
>>
>> Please report this error to your administrator.
>
> I'm confused, however, because my examination of the
database reveals the following:
> => select * from job__resource where
job__id='244053';
> job__id | resource__id
> ---------+--------------
> (0 rows)
>
> => d job__resource
>    Table "public.job__resource"
>    Column    |  Type   | Modifiers
> --------------+---------+-----------
> job__id      | integer | not null
> resource__id | integer | not null
> Indexes:
>    "pk_job__resource" PRIMARY KEY, btree
(job__id, resource__id)
>    "fkx_job__job__resource" btree (job__id)
>    "fkx_resource__job__resource" btree
(resource__id)
> Foreign-key constraints:
>    "fk_job__job__resource" FOREIGN KEY
(job__id) REFERENCES job(id) ON DELETE CASCADE
>    "fk_resource__job__resource" FOREIGN KEY
(resource__id) REFERENCES resource(id) ON DELETE CASCADE
>
> bric=> select * from job__resource where
resource__id='4449';
> job__id | resource__id
> ---------+--------------
>  244026 |         4449
>  242570 |         4449
>  242526 |         4449
>  232415 |         4449
>  232407 |         4449
> (5 rows)
>
> I don't see how the primary key requirement is being
violated, since the new job__id is clearly unique, and there
already exist multiple entries for this resource__id.
>
> Any thoughts?
>
> Thanks!
> Alexander
>
>
>
>
> Alexander Vallens
> System Administrator
> Architectural Energy Corporation
> http://www.archenergy.com
> Voice:  303-459-7463
> Fax:    303-444-4304
>
>

On Fri, 7 Sep 2007, Alexander Vallens wrote:
> Yes, we are running 1.10.2. The documentation you sent
seems to suggest that 
> the problem has been fixed in rev. 7760. I assume the
best way to address this 
> issue would be to upgrade to 1.10.3?

Or apply that patch
(assuming it's sufficient,
  i.e. no database-upgrade script involved, etc.).

Anyone out there using Bricolage to produce Docbook?  If so,
was it  
pretty easy to build your story types to produce valid
DocBook?

-Matt

On Mittwoch 12 September 2007, Matt Rolf wrote:
> Anyone out there using Bricolage to produce Docbook? 
If so, was it
> pretty easy to build your story types to produce valid
DocBook?
>
> -Matt

I'm interested in something like that too.
I've already started to build an OC to produce latex so I
can build a pdf from 
it.
I want to generate html pages and a printed docu from the
same source.
Any other ideas welcome

-- 
Regards
Rolf Schaufelberger

On Sep 12, 2007, at 8:59 AM, Rolf Schaufelberger wrote:

> I'm interested in something like that too.
> I've already started to build an OC to produce latex so
I can build  
> a pdf from
> it.
> I want to generate html pages and a printed docu from
the same source.
> Any other ideas welcome

Cool.  We have a rudimentary home-grown CMS that is
currently  
handling docbook creation.  We then take the docbook and run
it  
through processors to come up with a variety of output -
pdf, html, I  
think xml as well.  In the medium term future (next year?) I
want to  
move that stuff into Bricolage.  It's flexibility in that
regard was  
one of the things that made the product attractive to us. 
My  
programming coworker had some concerns about proactively
structuring  
elements in a way that will generate valid docbook.  We know
we can  
validate it afterwards, but we want to try to make sure it
is done  
correctly when people are editing it.

Not having looked at the DocBook schema (which I'm planning
to do -  
might be a good idea, no?), I'm told that there are funky
ways valid  
elements can nest.  For example, sections.  So I just wanted
to see  
if anyone who had built out elements or story types had
anything to  
say about how arduous/impossible the task of creating valid
documents  
might be on the Story Type/Element end.

-Matt

You are probably already along the DocBook road but I am
wondering if  
you considered DITA.  To me, Bricolage's story based content
model is  
more along the line of DITA topics than Docbook sections. 
That is,  
unless you were planning to make a single story an entire
DocBook  
book or article.

--Seth
On Sep 12, 2007, at 8:59 AM, Rolf Schaufelberger wrote:

> On Mittwoch 12 September 2007, Matt Rolf wrote:
>> Anyone out there using Bricolage to produce
Docbook?  If so, was it
>> pretty easy to build your story types to produce
valid DocBook?
>>
>> -Matt
>
> I'm interested in something like that too.
> I've already started to build an OC to produce latex so
I can build  
> a pdf from
> it.
> I want to generate html pages and a printed docu from
the same source.
> Any other ideas welcome
>
> -- 
> Regards
> Rolf Schaufelberger
>

===============================

Seth Gottlieb
Content Here
P.O. Box 60062
Florence, MA 01062
http://www.contenthere.net


office: 857.488.4386

===============================

*******************************************
Pan Mass Challenge Rider:
http://www.pmc.org/egifts/giftinfo.asp?EgiftID=SG0137
*******************************************

On Sep 12, 2007, at 9:14 AM, Seth Gottlieb wrote:

> You are probably already along the DocBook road but I
am wondering  
> if you considered DITA.

That I don't know.  But yes, as I said, we are already on
the docbook  
road.  Can we get off it?  Maybe.

> To me, Bricolage's story based content model is more
along the line  
> of DITA topics than Docbook sections.  That is, unless
you were  
> planning to make a single story an entire DocBook book
or article.

Interesting.  Our initial thought was that the document
would be  
broken up into different stories and then combined up at pub
time.   
That might be more manageable. But also poses a new round of
questions.

-Matt

On Wed, 12 Sep 2007, Matt Rolf wrote:
> Not having looked at the DocBook schema (which I'm
planning to do - might be
> a good idea, no?), I'm told that there are funky ways
valid elements can
> nest.

But you presumably don't have to worry about that
if you're generating it, only if you're receiving it.

>  For example, sections.  So I just wanted to see if
anyone who had
> built out elements or story types had anything to say
about how
> arduous/impossible the task of creating valid documents
might be on
> the Story Type/Element end.

We go in the opposite direction, processing XML docs
following the NLM DTD
to generate for example this page and its contents:
http://www.who.int/bulletin/volumes/85/9/en/index.html

Ideally it would be cool to have Bricolage elements
for every element defined in the DTD, though what we do
is much less rigorous than that....
With that, you could do a straight-forward transformation
of the NLM XML into bric_soap XML, and voila you're done.
But there are so many ways to display things. Maybe that
could
be done through CSS, though. In that case, though, why not
just upload the original XML files as media and not dick
around
with transforming it.

Anyway, what day is it? Generating documents. I think
Bricolage
can't currently constrain the elements sufficiently for a
general
XML schema. Like if some XML element is supposed to only
occur zero
or one times, it's impossible to say that with Bricolage
subelements.
[Insert here about being able to inherit/compose element
types.]
You can verify it from templates, though. Also from the
templates
you'd have to be anal, or wrap all data content in CDATA
sections.
I don't know any other limitations. Probably be tedious as
hell
for a user to enter DocBook elements into Bricolage.
I would like to see a story element type for DocBook,
though,
at least for amusement.

On Sep 12, 2007, at 9:41 AM, Scott Lanning wrote:

> On Wed, 12 Sep 2007, Matt Rolf wrote:
>> I'm told that there are funky ways valid elements
can nest.
>
> But you presumably don't have to worry about that
> if you're generating it, only if you're receiving it.

Presumably.  But, see your last paragraph here:

>  Bricolage can't currently constrain the elements
sufficiently for  
> a general
> XML schema.

>>  For example, sections.  So I just wanted to see if
anyone who had
>> built out elements or story types had anything to
say about how
>> arduous/impossible the task of creating valid
documents might be on
>> the Story Type/Element end.
>
> We go in the opposite direction, processing XML docs
following the  
> NLM DTD
> to generate for example this page and its contents:
> http://www.who.int/bulletin/volumes/85/9/en/index.html

> Ideally it would be cool to have Bricolage elements
> for every element defined in the DTD, though what we
do
> is much less rigorous than that....

We don't implement the whole schema, just a subset.

> With that, you could do a straight-forward
transformation
> of the NLM XML into bric_soap XML, and voila you're
done.
> But there are so many ways to display things. Maybe
that could
> be done through CSS, though. In that case, though, why
not
> just upload the original XML files as media and not
dick around
> with transforming it.

I think one of our goals would be to edit the DocBook using
Bricolage  
to take away some of the burden on the user (and us, so we
don't have  
to roll out another CMS - but maybe I'm asking too much). 
For  
example the way our course catalog is edited now is kind of
crusty.

> Anyway, what day is it? Generating documents. I think
Bricolage
> can't currently constrain the elements sufficiently for
a general
> XML schema. Like if some XML element is supposed to
only occur zero
> or one times, it's impossible to say that with
Bricolage subelements.
> [Insert here about being able to inherit/compose
element types.]

Well, yes, and you do have some control over
"required" or  
"repeatable" elements.

> You can verify it from templates, though. Also from the
templates
> you'd have to be anal, or wrap all data content in
CDATA sections.
> I don't know any other limitations. Probably be tedious
as hell
> for a user to enter DocBook elements into Bricolage.
> I would like to see a story element type for DocBook,
though,
> at least for amusement.

I suppose if we were intelligent about what subset of the
schema we  
implemented, we might be able to make it work.

-Matt