[wdmmg-dev] refactor .lib.solrhelp and .lib.browser into .lib.solr

Carsten Senger senger at rehfisch.de
Sun May 15 20:48:34 UTC 2011

--On Sonntag, Mai 15, 2011 21:31:58 +0200 Friedrich Lindenberg
<friedrich.lindenberg at okfn.org> wrote:

> On Sun, May 15, 2011 at 9:16 PM, Rufus Pollock <rufus.pollock at okfn.org>
> wrote:
>> On 15 May 2011 20:11, Carsten Senger <senger at rehfisch.de> wrote:
>>> I'd like to move the content of .lib.solrhelp and .lib.browser to
>>> .lib.solr
>> there's a reason it was called solrhelp: so you didn't have problems
>> with:
>> import solr
>> as solr is name of underlying library.

I see. I avoid relative imports an would always do

from wdmmg.lib.solr import x

but it's even better to move the .lib.browser stuff to

>>> and rename .lib.browser.Browser to .lib.browser.SolrBrowser.
>> No objections here.
> I don't fully get why it needs to be renamed, but go ahead ;-)

Only for clarity. Gardening. Both work with solr, and Browser is
a very common name which gives no hints about it's purpose.

>>> And does somebody know if these are used outside the main wdmmg package?
>> Doubt it.
> No, but its used pretty extensively within, so handle with some care
> ;) And wrt @properties take care to only make those explicit that are
> about value access, not those for lazy-loading.

I will be and don't think I do much more than the import changes.

>> PS: i think you should check suggestion about entry id naming with
>> Friedrich. I also think that (as per ticket) we should have some human
>> / search engine url niceness so urls were of the form:
>> /entry/{id}/{string-for-humans-but-not-used-by-backend}

I thought so too, but I started with the eu dataset and it has nothing
usefull to put there like transaction ids and descriptions.
The best I can come up with looks like .../{from}-to-{to}, e.g.


and this schema can easily become ugly (from the departments dataset):


And even with a short human readable segment at the end urls get long,
in this example 91 characters:



More information about the openspending-dev mailing list