couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Broerse <martin.broe...@gmail.com>
Subject Re: FolderDB - advice wanted
Date Sun, 21 Jul 2019 21:00:05 GMT
Hi Rene,

I actually don't see what you want advice on but I can say 2 things about
it.

   - Use CouchDB with keys like
   `rss_2_YYYY-MM-DD-hh-mm-ss-CATEGORY_SUBMENU_PATH` or
    `rss_2_CATEGORY_SUBMENU_PATH-YYYY-MM-DD-hh-mm-ss` depending on what you
   want to find with mango queries and use as value your JSON data in a `data
   `root key. like this
   https://my.couchcluster.com/bloggr/post_2_9F4D597F-037B-0037-8F64-917B1DDBA611
   to be able to switch to relational-pouch
   <https://github.com/pouchdb-community/relational-pouch> later.
   - Use a MIT, Apache or similar License but not GPL or LGPL if you want
   companies to use it. We have a policy at our company not to use and invest
   in GPL licensed code.

Play with Mango queries direct from Fauxton to see the advantage of using
rss_2_ like this

```
{
   "selector": {
      "data": {
         "key1": "s|string"
      },
      "_id": {
         "$gt": "rss_2_",
         "$lt": "rss_3"
      }
   }
}

```

- Martin

On Sun, 21 Jul 2019 at 18:50, Rene Veerman <seductiveapps@gmail.com> wrote:

> Hi.
>
> I like JSON a lot better than the SQL data model,
> but now that i've been using it for a few years,
> i find myself combining file system storage of lots of JSON files in many
> sub-folders into a web app,
> like news gathering with commandline PHP per N minutes from 280+ RSS online
> sources,
> into a PHP web-app that loads the latest news, via a web-powered PHP
> filesystem search of the latest new-items JSON files, stored on a
> filesystem thats got folders like
> ./YYYY/MM/DD/hh/mm/ss/CATEGORY_SUBMENU_PATH leading to JSON files.
>
> so now i want something more flexible. something that can give me a
> web-based treeview of data spanning many JSON-like files (in more
> complicated ways than my news app) and even into other file formats stored
> somewhere on the filesystem of some server.
>
> i plan to license this right from the start under a LGPL typed license,
> because i believe input from other developers is key to making a DB system
> that is not only easy to use, but also very efficient to run.
>
> i'd like the code to stay pure PHP, not even using the object oriented
> functionality of PHP, just plain properly named functions and their return
> values.
>
> i'll name this DB architecture FolderDB, and to prevent web-apps from
> forcing the server to reload (and decode!) many .jsone files upon a simple
> request to change something in some referenced .jsone file, i plan to run a
> single PHP server daemon that will respond to a yet to be written
> ASCII/UNICODE protocol.
>
> the file format itself, has to differ from JSON somewhat i think, and i
> also believe we can lose some of the overhead.
> i post this all here to hear your opinion, especially when it points to
> insurmountable problems related to my designs.
>
> i'm also interested to learn about how to add cloud redundancy to this DB
> architecture, preferably with tiered backup servers, or at least be
> prepared for such expansions of the DB architecture later on.
>
> here's the string based format that i came up with so far :
>
> JSON-Extended file format (ASCII / UNICODE)
>
> ------------------
> {
>     key1 : s|string value,
>     key2 : 2,
>     key3 : 3.4,
>     key4a : t,
>     key4b : f,
>     key5 : [
>         numbered array
>     ],
>     key6 : {
>         named array
>     },
>     key7 : url|/siteData/bla/bla/file.jsone,
>     key8 : key|key7/someKeyInsideFileBehindURLofKey7_key1/key1a,
>     key9 :
>
> url|/siteMedia/backgrounds/someFile.png||thumb|/siteMedia/backgrounds/thumbs/someFile.png,
>     key10 :
>
> url|/siteData/bla2/bla2a/file.odt||thumb|/siteData/bla2/bla2a/file.odt.thumb.png||thumbGenerator|URL
> }
> ------------------
>
> key4a = true
> key4b = false
>
> key1 would need it's value escaped, using \| and \,
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message