database

I didn't find anything I like.  I am disgusted.  I realize that all I want is a persistent array with transactions.  I don't even need a map because Lucene provides all the indexing I need.  So all I really need is this:

interface Db {
	byte[] get(long id);  // returned value may be null
	void put(long id,byte[] value);  // value may be null
	long add(byte[] value);  // returns id
	long size();

	void begin();
	void commit();
	void rollback();
}

I will probably just implement this myself.  What do you think?

I thought more about this and I think I will just use Lucene directly as the database.  Lucene effectively has versioning and handles write concurrency by simply having one global write lock on the whole index.  This is fine for small projects.  (Each project will get its own Lucene index.)  It should be fine even for an active forum.  What do you think?

I don't understand lucene very well, so I don't have a reliable judgement about it. It seems to work fine, but it lacks tools to browse existing data, run backups while the system is running, etc. This is why I would use postgresql in your case.

There are tools for both browsing data and backups in Lucene.  I don't think Postgres is a reasonable option for a small website.  Let's discuss this.  I actually want to dump Postgres for LOB and use Lucene instead to test how well this works.

We discussed this. We can give it a try, but this should be discussed on another thread.

lowering to priority 2 until Lucene is proven for LOB

Hugo, please give me feedback on my latest Lucene API for LOB in LOB rev 135.  If it looks okay, I will use it for Luan.

I assigned the LOB thread back to you.

Basic lucene works now but I want to discuss it with you on Skype.

We discussed this.

Here is some sample code.  Please let me know what you think.

Model.luan

The code is fine. I like how you use local functions in order to control visibility.

I have a few thoughts though. Why don't you create an update() function inside the base_user table? So we could have this:

local function base_user()
	local this = {}

	function this.doc()
		return {
			type = "user";
			id = this.id;
			user_email = this.email;
			user_email_lower = this.email.lower();
			user_password = this.password;
		}
	end

	function this.update()
		local doc = this.doc()
		Lucene.db.save_document(doc)
		this.id = doc.id		
	end

	return this
end

This would simplify the new_user() function. Actually, I think the new_user() function shouldn't save the user. For example, the code that invokes the new_user() could get the user and set other properties, like age, name, etc. So it should save the user only at the very end. Does this make sense?

Sure, it makes sense.  But instead this.update() I would call it this.save() .  But these are details, I just wanted to get a feel for how the code will look and I think it looks okay, cleaner than Java.

Here is a better version:

Db.luan
User.luan
m.luan

I agree, it looks much better now.

closing thread