Re: 2 questions: unique properties + history

Dear John,

Thank you for your detailed replies. I do not see the exact point of
multiple IDs either, I was asked to implement it.

Now I am still struggling with the Hyperdb class wrapper of the web
interface. My (lame?) question is how can I access items of classes via
their key property, or at least fetch the ID, like
db.status.lookup("resolved").

As I see, all operation requires the numeric ID of
the item (@link@ etc.). Let's say I want to add a button "Change
status to resolved" to the web page. To this end, I need the ID of
"resolved" item of status class (right?). I do not want to hardcode
to the HTML template that this is, let's say, 6. What is the easiest
way to retrieve the ID of the status with (key property) name
"resolved"? I can do it (loop through db/status/list, etc.), but none
of my solutions is nice... If not necessary, I don't want to use low
level methods, but if it is necessary, I will. :)

Regards,
Gabor


> 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.