Computer \Com*put"er\ (k[o^]m*p[=u]t"[~e]r), n.

1. One who computes.

	Name	Last modified	Size	Description
	Parent Directory		-
	GNoDbify-0.1.tar.gz	21-Apr-2008 15:54	417
	GNoDbify-0.3.tar.gz	10-Jul-2008 10:29	2.7K
	examples/	04-May-2008 16:43	-
	libgnodbify-0.1.tar.bz2	23-Mar-2007 13:57	207K
	libgnodbify-0.1.tar.gz	23-Mar-2007 13:57	313K
	libgnodbify-0.2.tar.bz2	10-Aug-2007 14:18	211K
	libgnodbify-0.2.tar.gz	10-Aug-2007 14:18	318K
	libgnodbify-0.3.tar.bz2	21-Sep-2007 13:28	211K
	libgnodbify-0.3.tar.gz	21-Sep-2007 13:28	318K
	libgnodbify-0.4.tar.bz2	04-Jan-2009 17:56	238K
	libgnodbify-0.4.tar.gz	04-Jan-2009 17:56	328K
	libgnodbify_0.4-1.diff.gz	04-Jan-2009 18:02	15K
	libgnodbify_0.4-1.dsc	04-Jan-2009 18:02	881
	libgnodbify_0.4-1.orig.tar.gz	04-Jan-2009 17:56	328K

About libgnodbify

Libgnodbify is an object/relational mapper that I started to write a few years ago as a tangent on another project. That other project did not end up going anywhere, but libgnodbify did end up being almost useful until I had had enough.

A bit later, I needed to do a project for work, and having an object/relational mapper written in C seemed useful for a while. I revived it then, and it is now somewhat functional (but see below). There is no support, though patches are welcome. It currently only works against postgresql, although in theory it should be possible to port it to other databases.

The perl bindings (also available from here, NOT from CPAN) contain some subroutines that might be useful if you want to use it with CGI.pm and its form generating stuff.

Known bugs

• The original goal of the library was to make it possible to have an object which would issue a glib signal when data was updated in the database; this would be accomplished through postgresql's NOTIFY system, and a set of triggers. Since I stopped working on the library until I started using it for that project at work, however, this code was never properly finished. It should not take an inordinate amount of time to debug and fix it, but I'm not interested in doing this myself anymore.
• The library is not particularly flexible against changes in the database. If a field is added to or removed from a table, you need to redo your gnodbify usage, and recompile a whole lot of software before everything will work again. Fixing this will need a rewrite (which I'd been working on, but again lost interest in).
• The library imposes a structure on the database: every table needs to have serial field called 'id' which must be its primary key.

Everything else works pretty well; and given that I'm supposed to commercially support a piece of software that uses it, I'm fairly certain it will remain that way for quite some time.

How to use it

You'll need to subclass gnodbify-object. This requires several hundred lines of code to do well; have a look at the mkobj script in the examples directory for an example of how to do this without reinventing the wheel. The mkobj script will also generate perl bindings, should you want that. It works, but it's a bit hairy -- if anyone feels compelled to clean it up a bit, be my guest.

A gnodbify subclass has only a few important methods: lookup (to look up an object by primary key), and new (to create a new object), destroy (to delete an object from the database). Data is implemented as object properties, so you can use the g_object_get and g_object_set methods to retrieve or modify data. When you set a parameter, the object should first be locked and then be flagged as 'dirty'; this creates a transaction and will make gnodbify perform an UPDATE statement in the destructor of the object (which is called once the object's reference count reaches zero). This can be forced with the _commit method. Finally, you can create manual transactions using gnodbify_begin_transaction and gnodbify_end_transaction.