Why does hexo use this database implementation? about warehouse HOT 4 OPEN

Good question. I wont speculate either. (well only a little)

One idea I can think of is that you can index all the assets and get access to it for use synchronously. With that it can support most template engines that people like to use. It just passes them this context:

https://hexo.io/docs/templates.html
https://hexo.io/docs/variables.html

For example a recent posts query:

site.posts.sort('date', -1).limit(10).toArray()

It's possible to do a lot more elaborate querying than that!

It's a big advantage not to have to install and manage a database server. Another advantage is being able to open a json file and search all the data in the raw form.

Scaling up is difficult. There are people using it with over 10,000 posts. It would be interesting to hear how that works for them. If we check hexo issues we might be able to find out.

Another json database is https://github.com/louischatriot/nedb which you may have seen. It doesn't have schemas though. The querying is like MongoDB which many libraries like to emulate.

When hexo was made some years ago was there anything that could even provide this functionality? Warehouse might be the best one!

What do you think the most common use case is for hexo blogs? 100 posts or less?

from warehouse.

I was also thinking about this, but from another perspective. Maybe it is even more naive, but I'm thinkig how much would it take, to upgrade datastore with in-memory database (for example LokiJS) for most heavy operations? How much speed improvement woud that give to hexo?

from warehouse.

Indeed, I looked at it, and Loki seem to be doing the job: fast, with persistence,...
If we were to do the transition, we would probably need to expose a wrapper over Loki

from warehouse.

I tried LokiJS, nedb, lowdb, and some others. Warehouse has a nicer API. We just need to document it better and support with examples.

from warehouse.