ORM Design Overview

Scud's ORM

This will be a overview of how Scud's object relational model is to be organized, to get a concrete footing for how the applications will best interface with him.

Ascii Relationship Diagram (Excluding Bot Object)

            +----------+
            |  SERVER  |
            +----------+
                 M
                 |
                 1
            +----------+
            |  NETWORK |
            +----------+
                 1
                 |
                 M
            +----------+
            |  CHANNEL |
            +----------+
                 1
                 |
                 M
+-----+     +----------+     +--------+
| URL |M---0|  MESSAGE |M---1|  USER  | 
+-----+     +----------+     +--------+

So in short, a Network (Such as Quakenet) has many servers (irc.quakenet.org:6667, us.quakenet.org:6667 etc) and also has many channels (#foo, #bar, ...). Each Channel has many of it's own messages, and each Message belongs to a User. Sometimes a Message will contain one, or many URL references.

The Bot Object

Currently the relational model is set so many bots can be on many channels, which means that more then one bot might be on the same channel-- which seems like it could lead to a problem of double-logging. This could be prevented, or filtered out at the logging stage, but it seems like it might be better to actually limit a channel to only having a single bot at any one time. The question is, which approach is best?

In the one to many option the Bot is related to the Network primarily, and the Network could have many bots. When a Bot is born to a particular Network, it queries to see which channels should be monitored, and finds which currently aren't and heads off to them to listen in. Never should two bots join the same channel (at the same time).

So for that information, the Channel should also hold a relationship to the Bot. With that in place, you could either ask the Channel who is currently monitoring it via Channel.bot or ask a particular Bot which channels it's actively monitoring via Bot.channels. You could also easily see which Channels should be monitored, but are waiting on a Bot to join, because Channel.bot would be None.

+---------+     +-------+     +---------+
| NETWORK |1---M|  BOT  |1---M| CHANNEL |
+---------+     +-------+     +---------+

So the Channel would have a Foreign Key pointing to the Bot.id.

The benefits of a many to many option would I presume mean better redundancy on a wider scale, e.g. with the right scalability, you could have two bots Alice and Ben watching over one Channel, each bot running on a separate server. Both would pass messages to the master program, and then the master would notice the same message coming from each Bot and then discard one. If Alice fell over and died, was kicked, or even banned then Ben would be ready to pick up the slack. In the case of kicks or bans, the distributed nature wouldn't matter, they could be running off the same box (depending on the ban's hostname specificity of course).

Getting to the many servers level would require a pretty big refactor, so perhaps it's best to just focus on the kick/ban benefit.

In addition the many to many option could use logic to essentially run as the one to many option anyway, there could simply be a max_bots_per_channel setting on the Network, or Application level which would limit it to that level.

Opinions?