db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r...@mankin.org.uk
Subject Re: Documentation and (slightly) strange update problem
Date Wed, 25 Feb 2004 14:17:33 GMT
As requested, here is the code


     /*
       This does not work. Since we retrieved using two column values
       it will save using those same two column values, but one of them
       has changed, so the save will fail.
      Objcontent link = new Objcontent(folder.getObjid(), getObjid());
      List l = ObjcontentPeer.doSelect(link);
      link = (Objcontent) l.get(0); // There can only be one instance
      link.setFolderid(parent.getObjid());
      link.save(); // This is the save() that does an INSERT instead of an
UPDATE
      */


// This one does work.
     List l = getObjcontentsRelatedByContentid();
LINK_UPDATE:
         /*
          This does work because we retrieve by PK and so the save will be by PK
          */
     for (Iterator iter = l.iterator(); iter.hasNext(); ) {
       Objcontent link = (Objcontent) (iter.next());
       if (link.getFolderid() == folder.getObjid()) {
         link.setFolderid(parent.getObjid());
         link.save();
         break LINK_UPDATE;
        }
     }


..and here is the relevant part of the schema

<database
  name="ermsdb"
  defaultJavaNamingMethod="java"
  defaultIdMethod="native">

 
  <table name="ERMSObject" description="Base Object Table">
    <column 
        name="ObjID"
        required="true"
        primaryKey="true"
        type="INTEGER"
        autoIncrement="true"
        description="Master object for all ERMS objects"
    />
    <column
        name="ObjType"
        required="true"
        type="CHAR"
        size="1"
        inheritance="single"
        description="Discriminates between folders, parts, documents and
versions"
    >
        <inheritance key="D" 
                class="Document"
                extends="uk.org.mankin.erms.Ermsobject"
        />
        <inheritance key="V" 
                class="Version"
                extends="uk.org.mankin.erms.Ermsobject"
        />
        <inheritance key="U" 
                class="UserResource"
                extends="uk.org.mankin.erms.Ermsobject"
        />
        <inheritance key="C" 
                class="DocClass"
                extends="uk.org.mankin.erms.Ermsobject"
        />
        <inheritance key="F" 
                class="Folder"
                extends="uk.org.mankin.erms.Ermsobject"
        />
        <inheritance key="P" 
                class="Part"
                extends="uk.org.mankin.erms.Ermsobject"
        />
        <inheritance key="B" 
                class="Box"
                extends="uk.org.mankin.erms.Ermsobject"
        />
        <inheritance key="R" 
                class="Role"
                extends="uk.org.mankin.erms.Ermsobject"
        />
    </column>
    <column
      name="Name"
      required="true"
      type="VARCHAR"
      size="255"
      description="Object Title; free text"
    />
    <column
        name="Description"
        type="VARCHAR"
        size="255"
        description="free text"
    />
    <column
        name="CreateDate"
        type="TIMESTAMP"
    />
    <column
        name="OpenDate"
        type="TIMESTAMP"
    />
    <column
        name="CloseDate"
        type="TIMESTAMP"
    />
    <column
        name="PurgeHold"
        type="BIT"
        required="true"
        default="0"
        description="Do not purge even when a purge operation is
        requested"
    />
    <column
        name="Status"
        type="TINYINT"
        required="true"
        description="{New, Open, Closed, ClosePending, ReOpened, Inactive,
Archived}"
    />
    <column
        name="Creator"
        type="INTEGER"
        required="true"
        description="A user ID; a FK"
    />
    <column
        name="Path"
        type="LONGVARCHAR"
        size="2048"
        required="true"
        description="The path name of where the object is in the
                    server's file store; it has nothing to do
                    with the logical name by which it referred
                    to in the EDRMS system."
    />
    <column
        name="Level"
        type="INTEGER"
        required="true"
    />

    <foreign-key foreignTable="User">
        <reference local="Creator" foreign="UserID"/>
    </foreign-key>
    <foreign-key foreignTable="SecurityLevel">
        <reference local="Level" foreign="Level"/>
    </foreign-key>

    <!-- fields specific to Document    -->
    <column
        name="DocTypeID"
        type="INTEGER"
        required="true"
    />
    <column
        name="Language"
        type="VARCHAR"
        size="255"
    />
    <column
        name="LockUser"
        type="INTEGER"
        description="The user who has checked out this doc"
    />
    <column
        name="LockTime"
        type="TIMESTAMP"
        description="When the document was checked out"
    />
    <column
        name="VitalRecord"
        type="BIT"
        required="true"
        default="0"
        description="A vital record is one that must never be
        deleted, even during a purge"
    />

    <foreign-key foreignTable="DocumentType" name="DocumentType">
        <reference local="DocTypeID" foreign="DocTypeID"/>
    </foreign-key>
    <foreign-key foreignTable="User">
        <reference local="LockUser" foreign="UserID"/>
    </foreign-key>

    <!-- Fields specific to document versions   -->
    <column
        name="Version"
        type="INTEGER"
        required="true"
        default="0"
    />
    <column
        name="DocFormatID"
        type="INTEGER"
    />
    <column
        name="Checksum"
        type="BIGINT"
    />
    <column     
        name="ParentID"
        type="INTEGER"
        description="The document to which this version belongs"
    />

    <foreign-key foreignTable="ERMSObject">
        <reference local="ParentID" foreign="ObjID"/>
    </foreign-key>
    <foreign-key foreignTable="DocumentFormat">
        <reference local="DocFormatID" foreign="DocFormatID"/>
    </foreign-key>
  </table>

 


  <table name="ObjContent"
        description="m:n join table specifying the content of each folder and
part">
    <column 
        name="ContentPK"
        required="true"
        primaryKey="true"
        type="INTEGER"
        autoIncrement="true"
    />
      <column
        name="FolderID"
        type="INTEGER"
        required="true"
        description="The ObjID of the containing folder"
    />
    <column
        name="ContentID"
        type="INTEGER"
        required="true"
        description="The ObjID of the content object"
    />

    <foreign-key foreignTable="ERMSObject">
        <reference local="FolderID" foreign="ObjID"/>
    </foreign-key>
    <foreign-key foreignTable="ERMSObject">
        <reference local="ContentID" foreign="ObjID"/>
    </foreign-key>

    <unique>
        <unique-column name="FolderID"/>
        <unique-column name="ContentID"/>
    </unique>

  </table>

</database>

On 25-Feb-2004 Scott Eade wrote:
> raph@mankin.org.uk wrote:
> 
>>As a newcomer to Torque, I would add that the lack of comprehensive
>>documentation has been my biggest difficulty. Is there a documentation
>>project
>>in hand? I think that such a project should even take precedece over fixing
>>bugs; if one at least has the wrinkles documented one can work around them,
>>and
>>AFAICT most are not major.
>>
> Everyone is welcome to contribute documentation.  Send it to this list, 
> the torque-dev list or add it to the wiki.
> 
>>
>>To move on ... I encountered some unintuitive behaviour when doing an update.
>>
>>
>>I have a m:n join table. It looks something like
>>
>>        create table link (
>>                PK integer auto_increment,      -- synthetic primary key
>>                parent integer references mastertable,
>>                child  integer references mastertable
>>        )
>>
>>Now, I wanted to move a child from one parent to a different parent i.e. just
>>update the 'parent' field in the link. I therefore selected on the
>>(parent,child) pair, amended the parent value and called save(). This is
>>where
>>things went wrong.
>>
>>Torque tried to save using the same criteria that it had used to select, but
>>I
>>had changed one of the values. It therefore did an INSERT instead of an
>>UPDATE
>>when what I wanted was that it should do an UPDATE using the primary key.
>>
>>The actual behaviour is clearly the intended behaviour. What I am questioning
>>is whether this is the correct behaviour. As we know from recent  postings,
>>every table must have a primary key otherwise save() does not save. Given
>>that
>>there always is a primary key, should all UPDATEs *always* use that key and
>>not
>>the selection criteria?
>>
>>I worked around my problem, but good documentation would have made life much
>>easier.
>>
> Please post the relevant schema and code.
> 
> Scott
> 
> -- 
> Scott Eade
> Backstage Technologies Pty. Ltd.
> http://www.backstagetech.com.au
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-user-help@db.apache.org
> 

-- 
                                       Never underexaggerate

Raphael Mankin
E-Mail: raph@panache.demon.co.uk
----------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org


Mime
View raw message