Piotras' blog: Archive

Read docs and blame me

Posted on 2005-08-01 19:00:25 UTC.

Never blame Midgard :)

MgdSchema API for midgard-php objects is updated.

I also updated mRFC 12.

Just send me mail or join #midgard if you would like to see docs more detailed.

Forget about midgard-php5

Posted on 2005-08-04 18:28:22 UTC.

Do not forget about midgard-php4. Module name may suggest only PHP4 support but we have php5 support since today. midgard-php5 and midgard-php4 modules have been merged to one midgard-php4 module and all the trick you have to do is to call correct php-config and correct phpize while trying to build midgard-php4 against PHP5.

Debian users who want to compile against PHP5 should do:

phpize5 

./configure --with-apxs=/usr/bin/apxs \
--with-apr-config=/usr/bin/apr-config  \
--with-php-config=/usr/bin/php-config5

make 

make install

zend.com is your best friend

Posted on 2005-08-14 02:21:12 UTC.

Do I really need to spend so much time on reading zend sources?

Do I need to write 1500 lines of code to find 15 working while making PHP extension using Zend?

I think I do not.
Zend and its products could make me happy.
Zend.com ( not linked, this is the last website you want to visit , trust me ) is a cure for everything.

Let's look at few sections.

Zend Books

• "Programmers that are relatively new to PHP will find tremendous value in learning the industry standard best practices for PHP development. Experienced PHP programmers will find the guide to [...]"
• "PHP 5 Power Programming"
• "PHP and MySQL Web Development"
• "Advanced PHP Programming"

My mistake, not this link. They talk about PHP , not Zend. I had to be blind.

ZendStudio

• "The Proven PHP Development Environment"
• "complete development solution for PHP"
• "database applications with PHP"
• "Zend Studio 4 Standard is designed for both PHP novices and advanced programmers."

My mistake, not this link. They talk about PHP , not Zend. I had to be blind.

"Zend Engine- The Heart of PHP"

They talk about Zend engine. ... hmmm that's all.
I expected something more than "zend engine".

My mistake, not this link. They talk about PHP , not Zend. I had to be blind.

More links with "Zend" title describe PHP.

Zend "Knowledge Base" returns "No matching results found" for zend API functions.

So what should I do? THE Contest!

Select the best match:

• a) they are extremely stupid
• b) they are very extremely stupid
• c) they are very very extremely stupid
• d) muzgi mają, no normalnie muzgi mają

Table and columns OK

Posted on 2005-08-18 01:59:35 UTC.

Good to know, first midgard database was modified automagically with midgard-schema command line tool which reads Midgard Schema XML file and use GObjects to modify database.

I had no this pleasure to create tables and columns ( but I will soon :) and I was able to modify database defined in new Midgard config file.

Usage is quite simple and trivial now.
`midgard-schema filename`



Filename is name of the file which exists in main midgard config directory.
/etc/midgard/conf.d in my case ( we always follow prefix defined for midgard-core ).

I used new OpenPSA2 schema and new MidCOM schema (global Midgard schema is used automagically) and it took "only" 35 seconds to modify database. It could be faster anyway , but I couldn't find any good way to create column if they not exist already in database. So what midgard_object_create_storage function does is:
1) Try to alter table and add column
2) if add fails try to modify it
( all in all types may change and database must be updated )

What about some usefull debug argument used with midgard-schema? There is no need to have it. Debug level is defined in configuration file. So database modification output ( with Loglevel set to message ) looks like this:

midgard-core(m):  Table and columns for 'NewMidgardSnippet' OK

midgard-core(m):  Column password for password property not created

Something's bad with password property ( message is not clever at this point , but believe me I modify table and write this blog, and this is initial midgard-schema usability ).

Let's switch Loglevel to debug ( default is warning , so such messages won't be printed except errors and warnings ).

Schema(d):  Type NewMidgardPerson

midgard-core(d):  query=CREATE TABLE IF NOT EXISTS person(id int(11) NOT NULL auto_increment, PRIMARY KEY(id))

midgard-core(d):  query=ALTER TABLE person ADD password varchar(255)

midgard-core(d):  query failed: Duplicate column name 'password'

midgard-core(d):  query=ALTER TABLE person MODIFY password varchar(255) 

midgard-core(d):  query failed: Specified key was too long. Max key length is 500

I wonder about this error. PRIMARY KEY and indexes wasn't touched.

BTW, log messages ( which can be logged to file ) starts with log domain name.So here this is very clear that we use external application which uses midgard-core."Schema" is a domain name defined for midgard-schema application.

Now think about midgard-apache and midgard-php combined log file and you will get very clear picture of Midgard :)

With possibility to add own messages to log file, even from PHP script you will source of your problem faster and easier. Just watching step by step what is going on :)

1.7.1 release delayed

Posted on 2005-08-24 19:17:02 UTC.

Yesterday I sent mail to dev@midgard-project.org list about delayed release. The main reasons why I did it:

We have not fully confirmed memory leaks in latest stable release, and we couldn't confirm attachments bug. Luckily the second one is fixed now and seems like the first one should be too.

Quoting myself:
"The problem with memory leaks in midgard-php4 may be casued by default_properties hash initialized per every class per request and not fully freed at request end. Currently we do not fully follow Zend API to add class members and such members are directly added to zend_class_entry' default_properties hash.

Good news is that I managed to write wrapper which creates zend_entry_functions structure on the fly. It means that we do not have to set class members , but instead we create real object constructor. All objects initialized have properties set and classes which extend base midgard classes have also default members ( properties ) without any need to write own constructor.

And it means that we can register *all* midgard types found in all schemas when module is initialized. Only once when module is loaded and save valuable time when request is initialized. The only one problem here is that all classes are available for every host. To make it "safe" we can use
objects methods only and only when class exists in request schema. In any other case every method should return at least "Access denied"."

Now , good news is : new classes registration procedures are finished , seems to be very stable and what is more important we have the same support for PHP5.

I didn't manage ( yet ) to write additional macros which should refuse any method call for objects not defined in schema. But now I think it is not mandatory for 1.7 branch as we do not support any high level applications with new Midgard technologies.

So, we just wait for developers who test latest branch and we can release quite new release :)

New daily snapshots for cvs branch

Posted on 2005-08-26 15:57:11 UTC.

No doubt. It had to be done.

http://www.midgard-project.org/nightly/branch/

Quite new daily snapshosts builded for latest Midgard CVS branch.  Just download ready to use tarballs instead of updating sources from CVS branch.

Dbcreate=yes

Posted on 2005-08-31 16:23:28 UTC.

Quite new configuration option for new Midgard configuration files.
Command line tool midgard-schema is now more "clever" if such option is set to "yes". MgdSchema itself is also "clever" as new attribute "dbtype" is now recognized. Such attribute is used only when columns in table are created or modified. Typical MgdSchema types just ignore this attribute, or better , do not use it. Thanks to Torben for such proposal.

I created today new database ( this can not be done with midgard-core yet ) and used midgard-schema to create tables and columns. dbtype attribute was indeed needed and perfectly helped to modify columns.

Host type's table ( for example ) looks bad with default values used in schema.

 describe host info;
+-------+--------------+------+-----+---------+-------+
| Field | Type         | Null | Key | Default | Extra |
+-------+--------------+------+-----+---------+-------+
| info  | varchar(255) |      |     |         |       |
+-------+--------------+------+-----+---------+-------+

We should have another type. Absolutely no varchar. What is to be done is to edit schema file and add correct dbtype if default type is not correct.

<type name="midgard_host" table="host">
[...]
<property name="info" type="string" dbtype="set('auth')"/>

Run midgard-schema again ( empty db without records should be created or modified in less then 10 seconds ).

  describe host info;
+-------+-------------+------+-----+---------+-------+
| Field | Type        | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+-------+
| info  | set('auth') | YES  |     | NULL    |       |
+-------+-------------+------+-----+---------+-------+

This database has also new openpsa2 and new midcom tables created.

describe midcom_group_virtual;
+------------+--------------+------+-----+---------+----------------+
| Field      | Type         | Null | Key | Default | Extra          |
+------------+--------------+------+-----+---------+----------------+
| id         | int(11)      |      | PRI | NULL    | auto_increment |
| component  | varchar(200) | YES  |     | NULL    |                |
| identifier | varchar(200) | YES  |     | NULL    |                |
| name       | varchar(255) |      |     |         |                |
| guid       | varchar(80)  |      | MUL |         |                |
| sitegroup  | int(11)      |      | MUL | 0       |                |
+------------+--------------+------+-----+---------+----------------+

PRIMARY KEY is created , and guid and sitegroup columns too. All is done automagically :)