So it seems the OO came in handy, it is now possible to query an arbitrary
amount of different Redis databases at the same time, host, port and key
prefix are stored/encapsulated in each Redis instance.

The big new thing is the prefixing to avoid key conflicts between projects
running on the same machine, it is a must have really.

I've also added it to the ext library:
https://bitbucket.org/hsarvell/ext/raw/fd41e8e8f43de04b6a46474809bc0c4099fa20b6/redis.l



On Mon, Nov 26, 2012 at 9:42 AM, Henrik Sarvell <hsarv...@gmail.com> wrote:

> I'm always keeping my options open so I don't have to rewrite a lot of
> stuff later if I realize I need for instance encapsulation.
>
>
> On Mon, Nov 26, 2012 at 9:21 AM, Thorsten Jolitz 
> <tjol...@googlemail.com>wrote:
>
>> Joe Bogner <joebog...@gmail.com> writes:
>>
>> Hi Henrik, Hi Joe,
>>
>> > Thank you for sharing. I have also thought about using redis for
>> > session state.
>>
>> I find that quite interesting too.
>>
>> > I tend to use picolisp in more of a functional form possibly because
>> > its a breath of fresh air after 10 years of oop in c#.  I sometimes
>> > wonder when its a good fit to mix in oop in picolisp.
>>
>> The last sentence addresses a question I have (or rather two question
>> about one topic):
>>
>> Say I want to write a parser in PicoLisp that parses Org-mode files
>> (with their outline tree structure) and stores the structure and
>> contents of the file in persistent objects in a database, allowing to
>> reconstruct the file on demand (and to query the content, recombine it,
>> or to use it in a web-application).
>>
>> The tree-structure of the document could be represented naturally by a
>> class hierarchy, and each element-class could not only store the
>> elements content and meta-data, but also have specialised methods for
>> parsing org-mode-elements of its type. So the main parser only would
>> have to recognize an element-type, create a new object of this type,
>> and call its parsing method that stores all the stuff inside the element
>> as well as its meta-data in 'This.
>>
>> Questions:
>>
>> 1. Would that be a reasonable application of oop in PicoLisp? How does
>>    it compare to parse a wiki-file and store the nested elements in a
>>    nested list?
>>
>> The reason I would want oop is to allow for big data and to be able to
>> quickly select/filter elements and to export them to some kind of
>> thematic wiki-file (agenda files that show entries for dates, or topics,
>> or certain tags etc. )
>>
>> 2. What about version management in the database (without reinventing
>>    GIT or so)?
>>
>> Since Org-mode files are plain text, VC like Git is perfect to manage
>> changes over time. What if such a text-file has been parsed and its
>> content stored in a OO-PicoLisp DB -  how would one deal with changes,
>> updates, keeping history without starting to write its own version
>> control system? Simpy check if the original text-file has changed, and
>> if so, parse it again and replace the content in the already existing
>> objects?
>>
>> Or is there a smarter way that minimizes parsing and stores only the
>> diffs, keeping the history somehow?
>>
>> --
>> cheers,
>> Thorsten
>>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>
>

Reply via email to