search

Signbank / Global-signbank

An online sign dictionary and sign database management system for research purposes. Developed originally by Steve Cassidy/ This repo is a fork for the Dutch version, previously called 'NGT-Signbank'.
http://signbank.cls.ru.nl
BSD 3-Clause "New" or "Revised" License
19 stars 12 forks source link

Create cronjob that removes Signbank packages older than a day #238

Open Woseseltops opened 7 years ago

Woseseltops commented 7 years ago

Related to https://github.com/Signbank/NGT-signbank/issues/187 . Currently, all packages that are requested are saved on the server, while they are only used once. This eats space for no reason.

susanodd commented 5 years ago

I found a bug with filenames in Signbank packages. It was something to do with constructing the paths for filenames when special characters are in them. It was causing the package generation to crash (when such a filename with accents exists - on my local machine test data). I've fixed this, it just needed the paths to be created using python os.path.join to make sure they are paths.

I also encountered all the packages files mentioned in this issue. (I was trying to find out where to attach the debugged code, if there was any issue open for Packages.)

How do you suggest that removing the old package files should be done? Remove old ones when a new one is to be created?

Additionally, in the API_FIELDS setting, it lists field idgloss.

(I am busy adjusting hard coded lists of fields, that's how I got to the packages code, because it calls some older functions that have hard-coded lists of fields.)

The question is: Field 'idgloss' has been subsumed since the packages code was written. Currently, the Annotation ID Gloss translations are (also) output to the Package file. But nothing is output for "idgloss" in spite of it being in API_FIELDS. (Because this isn't a field in Gloss anymore. It's a property, so it doesn't get found doing a loop over the _meta fields. The setting is basically ignored because none of the Gloss fields are in this list.)

What to do about API_FIELDS = ['idgloss'] Should this be something else? I assume it should work for whatever fields the user wants to put in this setting.

In the current implementation, if one changes (on the local server) this list to e.g., API_FIELDS = ['idgloss', 'handedness'] (as an example, for testing purposes) Then the "data" shown in the json output has the numerical machine value for 'handedness', not the human name for the field. Would you like this altered @ocrasborn ?

susanodd commented 3 months ago

What about this issue? The API is being extended.