Piotras' blog: Archive

Bread, electricity and Midgard2

Posted on 2007-05-01 09:30:11 UTC.

/usr/lib/pkgconfig/*.pc
/usr/lib/*.a
/usr/lib/*.la

gda-sqlite

gda-sqlite.install file should contain:

/usr/share/libgda-3.0/sqlite_specs_*.xml

Other issues

I have no idea why all sqlite spec xml files seems to be missed. Normally ( when compiled for i386 architecture ) gda library looks for spec files in lib directory and then in share one. When packages are compiled for armel architecture , gda looks for spec files only in lib directory.
To make libs working correctly I did this trick:

rules file

cp $(CURDIR)/debian/tmp/usr/share/libgda-3.0/sqlite_specs_*.xml $(CURDIR)/debian/tmp/usr/lib/libgda-3.0/providers/

gda-sqlite.install file

usr/lib/libgda-3.0/providers/*.xml

There are other xml and dtd files which should be correctly copied for debian packages, but there are only warnings thrown without them.

More beauty for Midgard or midgard-python in action

Posted on 2007-05-04 10:37:18 UTC.

Some day I had read about beauty and a Python. And yesterday I though "Why there's no Python's beauty for Midgard?" Python C API is very well documented so I couldn't wait any longer. I started with MidgardDBObject, MidgardObject, MidgardConfig and MidgardConnection base classes... and commited initial bindings.

About two months ago I wrote about creating Midgard unified configuration file and SQlite based personal database using PHP bindings.

Today I can do the same with Python.

import gobject
import midgard

config = midgard.config()
config.set_property('dbtype', 'SQLite')
config.set_property('database', 'midgard-test')

if config.save_file("midgard-test", 1):
    print "Configuration file created successfuly!"

Looks promising :)

midgard-apache, first requests

Posted on 2007-05-09 09:38:44 UTC.

First requests using new midgard-apache module :)

What's changed?

• Apache module initialize core's MidgardRequest object so it's available in midgard-php extension without need to write hacks.

It means that one should be able to write the same PHP application for command line and for web environment.

• $_MIDGARD global array has new key pages initialized as array with midgard_page objects.

All pages found from url are stored in this array, so there's no need to get page object during the request as it's already available. This array is always initialized for website. At least it always has host's root page available.

$_MIDGARD['pages'][0]

Always contain root page.

• midgard-root.php file is parsed after connection for request is established. Not before.

$_MIDGARD superglobal is available in any self defined root file. In the first line of it. You do not have to initialize your application from code-global page element. You can initialize it in file, before midgard style engine starts.

My simple test root file looks like this:

<img src="/spider-admin/spider_logo.png">
<?php
    foreach($_MIDGARD['pages'] as $page) {
        echo $page->name;
        echo " &raquo; ";
}
?>

To get my screenshot I requested page with such url:

myhost:8101/spider-admin/topic/article/1

And of course $_MIDGARD['argc'] is 1 and $_MIDGARD['argv][0] is "1". spider-admin, topic and article are stored in $_MIDGARD['pages'] as 0, 1 and 2 index.

BTW, with very first request I did:

print_r($_MIDGARD);

And firefox wanted to install missed java runtime to run included plugin. What? I realized that print_r also printed 'article' midgard_page's content which contain java editor...

That's fun , I found java editor in application which I use for years at the moment when I completely rewrite midgard-apache and midgard-php ;)

Midgard 1.8.4 is coming

Posted on 2007-05-17 20:38:16 UTC.

This week I fixed another very important sitegroup related bug in midgard-core. As current sitegroup rule for objects is clear , the issue I found raised very ugly problem. Class constructor unfortunatelly set object's sitegroup even if object has been fetched from database. "Fortunatelly" it only affected object created by root user, which happens almost only when midgard sitewizard creates new host.

Interesting, I found this issue solved in CVS HEAD ( aka 1.9 ), and never thought it exists in stable branch.

So 1.8.4 ( instead of hotfixes ) must be made , just because of this one issue and few minor found in midgard_object_class PHP bindings. The latter is interesting ( as others issues found in ZE1 ). When you write code in C , you must know when you return NULL and when ''. But ZE1 ( or maybe even ZE2 ) never tells you when '' string is "marked" by engine as NULL...

Ah, I could forget. Datagard handles database updates much nicer now. Randomly "not updated" database problem is fixed.

Debian users should love midgard packages when installing 1.8.4.

At last we have meta midgard package , so

apt-get install midgard

installs everything you need to have midgard running in few minutes.

Midgard-data from debian packages increases memory_limit in php.ini files ( 4 or 5 or both ).
After installing midgard you have brand new midcom-indexer package, which provides midcom indexer files and init.d script which starts automagically when package is installed. Needless to say. As soon as you create new website with midgard sitewizard, indexer is waiting for you.

Important note! Debian package uses /var/lib/midgard/indexer directory for indexer. If you already use it ( self compiled ), fix your paths and copy indexed db files to this directory.

I have been testing indexer with few java sdk. non-free sun ones, kaffeine, gij-4 and free-java-sdk. The last one seems to be the best choice , so it's installed as indexer dependency and indexer uses its files directly instead of /usr/bin/java for example which can be linked to other java binary in your case. And something obvious , you do not have to remember about lucene library anymore. I think midcom-indexer does all out of the box.

In other news. I try to make Midgard2 as cool as possible. And it looks like soon we should be able to install Midgard2 library together with Midgard1 one.