Re: 2 questions: unique properties + history

Hi Nagy:

In message <20210222234654.31acc576@Dell>, Nagy Gabor writes:

>I have read the guide "Customising Roundup", and I started to build by
>own tracker. I ran into two questions:
>
>1. Is it possible to tell Roundup to enforce the uniqueness of more
>than one property of a class?

>I guess that Roundup verifies that the key property is unique
>(this seems to be an analogue of PRIMARY KEY in rdbms).

The id is unique and IIRC is really the PRIMARY KEY within the
database.

The setkey(property) IIRC indexes that field and requires that it be
unique.  But there is only one key property. This is used by status
for example to make the status names unique. I assume you found the
details in customizing roundup.

>Can we set a unique attribute for some other properties,
>e.g. setunique(prop), like the UNIQUE constraint in rdbms? [...]  Or
>these types of checks must be done in an auditor?

There is no "unique" or "index" setting for a property like
"do_journal" or "quiet" .  (Note "indexme" controls full text
searching, and does not create a unique index on the field.)

You may be able to use an auditor to query the database on create or
edit to search the database field to verify that the new value is unique.

I would probably accept patches for the rdbms and anydbm backends to
add this. Especially with test cases providing 90% or more coverage.

>(In some use cases, there are more than one IDs, one for internal
>usage, and an other one for being the part of a larger system.)

I am not sure how to interpret this.

Let's say I have a part named widget-2cm. The vendor part number is
stored in the vpn property. The part also has a part number within my
company stored in the pn property. I require that both vpn and pn are
unique within their properties. So I could have part number 3 for one
part in vpn and part number 3 for a different part in pn, but only one
part has its pn=3 and only one part has its vpn=3. The part name
(widget-2cm) would be the key field so I could reference/look it up by
name.

Is this a concrete example of your use case?

>2. I will have to do some statistics on my tracker in the future. To
>this end, I have to carefully journal everything. By inspecting
>Roundup's source code and the database created by Roundup, I think
>Roundup journals every change on items (unless do_journal='no' is set),
>even if a String property is changed.

I claim this is correct.
 
>And the history format is described in the journal method of Class
>class in roundup.hyperdb:

That's the journal format. The history produces HTMl with that info IIRC.

>The history "list contains tuples of the form
>(date, tag, action, params)",
>
>where the action parameter can be (according to addjournal method of
>Database class): 'set', 'create', 'link'/'unlink', or
>'retired'/'restored'.

Correct.

>And I can figure out from the implementation of context/history, how to
>process the history entries. (Unfortunately, context/journal is not
>implemented. :)
>
>Am I right?

Yes. Again an implementation of context/journal and the HTMLJournalEntry
would be useful.

You should be able to create an extension that uses the
db._db.getjournal(classname,nodeid) (where db is the same as
context.db). This should return a list of tuples of the form:

     (nodeid, date.Date(date_stamp), user, action, params)

(yes using _db is icky but....)

>+1. My lame bonus question:
>Can I change the initial id (of issues) from 1 to an other number? :)
>(To easily "continue" the numberings of an old issue tracker.)

There is a setid method in the database. But it is not immediately
obvious to me how to use it. It may be usable from initial_data.py
as db.setid('issue', 23345) but I have never used it.

I think the "easiest" way to do this is to use the importtables
function in roundup_admin to seed the id.

You would create a csv file in a format that matches the export format
for your schema. It should consist of only one issue. Edit the id of
the issue to a number 1 less than you want the number of your first
issue (IIRC, the import set up the next ID to be the maxid+1 in the
import file, but I could be wrong.) This should result in setid()
being called and allow you to start at the right number.

Ralf, it seems there is another way to do this, but I didn't find
anything searching the wiki or mailing list. I think this was done when
roundup issues were moved from sourceforge to a roundup instance.

Hopefully somebody has better alternatives than the ones I have
proposed.

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.