Consider using MongoDB to persist the database about room.js HOT 17 CLOSED

+1

from room.js.

Yeah I think I'm tackling this next, I keep running into stupid bugs related to how I'm storing the DB.

from room.js.

Might hack at this over the weekend.

from room.js.

Here's the problem / challenge: Mongo, or any other database engine for that matter, is going to be asynchronous. Almost everything in Node is asynchronous. This means that any room.js object lookups would have to be asynchronous as well. This severely affects verb code. As some examples:

The code for $room.announce

[msg] = args
obj.tell msg for obj in @contents when obj isnt player

would have to become something like:

[msg] = args
@getContents (contents) -> # async operation which does io then calls the callback with results
  obj.tell msg for obj in contents when obj isnt player

This isn't that bad, but I've assigned these "global" variables for some commonly used objects, which I would have to do completely differently now:

$player.say

msg = "\"{white|#{argstr.trim()}}\""
player.tell "{gray|You say #{msg}}"
@announce $gender_utils.agree "{gray|#{player.name} %says #{msg}}", player

would become:

msg = "\"{white|#{argstr.trim()}}\""
player.tell "{gray|You say #{msg}}"
$ '$gender_utils', ($gender_utils) -> # jQuery style object querying of some sort
  @announce $gender_utils.agree "{gray|#{player.name} %says #{msg}}", player

So this introduces the $ query function. I assume things like this would work:

# get an object by id
$ '#5' (thing) ->
  ...

# get an object by some unique identifier
$ '$string_utils' ($string_utils) ->
  ...

# or why not just use sequential ids for objects unless a specific id is given, 

# multiple queries seperated by commas
$ '#5, #string_utils, #forest', (thing, string_utils, forest) ->
  forest.getContents (contents) ->
    ...

# attribute selector; also, all db operations would be async too...
$ 'name="The Forest", name="Wooden Sword"', (forest, sword) ->
  sword.moveTo forest ->
    # sword is now in the forest
    ...

# property selector
$ 'prop[description="red and round"]', (red_ball) ->
  old_desc = red_ball.description # sync reads
  red_ball.setProperty 'description', 'it bounces', -> # async writes
    # property is now set
    ...

This makes the verb code a lot more messy... I don't know how much I like this... It also makes programming verb code a lot less approachable to newbie programmers. I wanted it simpler than this. It takes newer programmers a while to wrap their brains around callbacks and async stuff.

So this is why my original idea was to write my own in-process, in-memory js database library, because it would also be synchronous.

Just some ideas.

from room.js.

( Referencing issue #8 )

from room.js.

So, for context, you mention

[you] keep running into stupid bugs related to how [you're] storing the DB.

Like what?

from room.js.

https://github.com/ypocat/nodejsdb goes over some options for in-process datastores.

from room.js.

Well problem number one:

When creating a new object, it determines the lowest unused object ID, and uses that for the new object. This sucks because this happened: I made a new object which took the ID number of a room that used to exist but was deleted at one point. Now my randomly walking mobs walk around and go through an exit which used to point at that room, but now points to this new object (which isn't a room). Now they're stuck inside it, because there's no "go" verb inside that object. (They continuously cause exceptions).

Fix: Don't reuse IDs.

As for those databases, I've looked through them all. They're all asynchronous. I'm really leaning towards keeping verb code synchronous. For clarity, ease of coding and some other reasons.

from room.js.

What about a heredis, redis, and node-redis stack?

from room.js.

Like I said, ALL database engines are asynchronous. Unless we do something like load the entire object database into memory on app start, we would introduce asynchronous style programming into every object finding operation in verb code.

I HAVE thought about doing it that way; use mongo as the storage engine instead of a flat json file, but still just load the entire object list into memory on app start. It wouldn't really change much, and we wouldn't get the benefits of doing mongo queries to search for objects.

So ultimately I think this is the decision I'm leaning towards: develop a jquery style, or mongo style query interface, but keep it synchronous, and keep the entire database in memory. This would let you do things like this (jQuery style):

[thing, string_utils, forest] = $ '#5, #string_utils, *[name="Forest Clearing]"'
things_in_the_forest = $ forest, "parent=#{thing.id}"  # <= all objects in the forest that inherit from #5

from room.js.

Right. I thought about Redis since it IS in-memory, but of course that's different from in-process. Silly node noobage.

from room.js.

http://www.slideshare.net/robtweed/globalsdb-its-significance-for-nodejs-developers ?

from room.js.

Page 15: Why use Globals: * Synchronous coding.

Bingo!

Just cause something is in-memory or even in-process doesn't mean it has a synchronous API. This Globals thing apparently does. Good find, I will investigate further.

from room.js.

Hey look, there IS a way to do synchronous mongo queries: https://github.com/olegp/mongo-sync/

from room.js.

That looks way easier.

from room.js.

Heh, don't think I full appreciated this at the time:

Now my randomly walking mobs walk around and go through an exit which used to point at that room, but now points to this new object (which isn't a room). Now they're stuck inside it, because there's no "go" verb inside that object. (They continuously cause exceptions).

Little living NullPointerExceptions. Delightful.

from room.js.

lol... amazing. Speaking of... 3.0 doesn't have cron yet, no scheduled events...

from room.js.