forum design

This is my initial design.

The Lucene table will contain only 2 types of records: users and topics (threads).  A topic record will contain a "content" field which will contain the Luan needed to construct the topic.  This will include constructing the array of posts in the topic.  Posts will be Luan objects but will not have records in Lucene.  All searches will be against topics, not posts.

Forums will be defined in Luan config files.  The forum ID will just be a unique string.  Each topic will be in a forum and the lucene record of the topic will have a "forum" field containing the forum ID.  Forums are independent from each other.  There is no forum hierarchy.  So one can list topics in a forum or all topics.

The home page of most boards (a board is a forum site) shows a hierarchical list of forums.  I will support this but it is purely aesthetic and has no meaning.  Suppose I have an animal board with a home page like this:

animals
        mammals
                dogs
                cats
        reptiles
                lizards
                snakes

Only the leaf nodes (dogs, cats, lizards, snakes) should be forums.  The other things are just categories and shouldn't be clickable.  If you want more general forums, do this:

animals
        general animals
        mammals
                general mammals
                dogs
                cats
        reptiles
                general reptiles
                lizards
                snakes

This structure of categories and forums will be stored in a config file and won't be in the lucene db and won't have much impact on the code.

I think this is a very simple design which does everything that a basic forum needs.  Hugo, comments?

I think this is a good start. I wonder what exactly will be stored in the topic "content" field. If it is just a lua table, then that's fine. If you plan to save more than that, then you may have problems.

I just plan a Luan table but I am curious what problems you think storing complex Luan would cause.

Storing complex code is a bad idea because replacing it later will be a horrible pain. Luan isn't stable and we are still discussing concepts, keywords, etc. The database should have only data, never code.

I don't agree.  Lua was originally designed specifically as a data persistence language.  Lua persistence is discussed in chapter 12 of "Programming in Lua".  An old version is here:

http://www.lua.org/pil/12.html

Luan is now a subset of Lua with exactly the same keywords as Lua, so it should be safe.  If an issue comes up, I can deal with it.  But I think the concept of using Luan for persistence should be used freely as was originally intended in Lua.

My main concern is that the topic "contents" field could have luan code that prints HTML just like a java servlet. If you want to change how topics are presented, then you would have to run a horrible script to replace the pieces in the database. This is not acceptable when you have the option to keep the logic out of the database.

I agree with this.  Storing Luan is fine but storing API calls is not okay.  Basically there should be no "require" calls in persisted Luan.

Okay. I would still try to leave the data as clean as possible, but some small logic would be acceptable. You can go ahead with this.

closing until I discuss LOB

http://international-dating.63364.x6.nabble.com/Reconsidering-this-business-tp563p610.html