[note: I'm not subscribed to this list, just posting to let Anthony have a
breather]
In order to help people understand roundup's capabilities, I've written a
features page, which is accessible at http://roundup.sf.net/doc/features.html
... it's not complete, since I've only just hacked it together. I'll flesh it
out as I remember stuff that Roundup does :)
Gordon McMillan wrote:
> Hmm. From a quick look, it appears that the
> abstraction tends to hide the roundup schema
> from the DB schema. I suspect that what Andy
> wants is for the DB schema to reflect the
> roundup schema so he can query directly
> on those "arbitrary" properties.
That's correct. Roundup's hyperdb is a relational layer over anydbm-alikes.
The intent was to make it available to people who don't/can't want/have an
SQL database. Putting a real SQL database in the backend doesn't actually
gain much - the journals will be stored much more intelligently, but for the
most part, it'll be a lot of effort for little gain. Most of the table
joining that you need to do is already done automatically by the hyperdb.
Having db-level support for locking would be nice though (roundup implements
its own locking). I'd hope that we can turn this on in the bsddb[3] backend
Real Soon - but I'll need to do a bit of reading before I can do that ;)
Michael Hudson wrote:
> Ooh! I just stumbled into another one: serving up text attachments as
> Content-Type: text/plain! I'm not the only person who gets pissed off
> with having to save files to disk for no good reason, am I?
Roundup gets this right - it uses the content-type specified in the attachment
if submitted by email, or uses python's mime guessing if submitted through
the web. It also serves the file up with the correct name.
> 2) Not having this lunatic distinction between patches and bugs or
> restrictions on who can add files to issues, and let people delete
> at least their own attachments.
Files may be attached to just about anything in roundup - the schema's
completely flexible (so yes, you can attach files to people, people to issue
states, messages to files, ...)
You could also set your schema up so files come in different classes (roundup
hyperdb classes that is) ... so files used in different contexts can have
different attributes. Those attached to an issue (bug, feature, whatever) can
have a state (pending, accepted, rejected, deleted) and those attached to
people can have a type ('favourite car', 'mugshot', ...) and so on.
Apologies in advance if I missed any outstanding questions,
Richard
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4