Re: Working on core configure

On Jul 31, 2005, at 13:01, Jukka Zitting wrote:
> PS. I'm planning to setup an automated Midgard build and test suite  
> at the SourceForge compile farm. Could someone (bergie) add me  
> (jukkaz) to the SourceForge midgard project as a developer so I  
> could better use the SF machinery for this?

Done.

The idea sounds good 

> Jukka Zitting

/Bergie

Re: mRFC 0018: Adopting the UUID and URN standards

Hi,

--Jukka Zitting wrote on 2005-07-31 11:02:
>> Anyway , I would like to propose /[0-9-a-f-]{32,80}/. It will be backward compatible,
>> especially when you think about objects's update which could be done with object
>> itself.
> 
> {21,80} is a superset of {32,80} so I see no compatibility problems with 
> my proposal. And while both UUIDs and current GUIDs are 32+ characters 
> wide, we might come across some shorter external UIDs that would be nice 
> to keep.

I think 21,80 should be no problem, as at least I have to change all GUID checks
anyway -- I usually was comparing == 32 not >= 32.

The only thing is that for the comaptibility method there must still be a safe
way to distinguish UUIDs from the old DB IDs as long as they're still "in use".
For the record: In MidCOM, the recognition of those has to be reworked as well,
as I is_numeric all regular DB IDs for safety reasons.

Bottom Line: I'm fine with 21, as we have to rework all ID/GUID stuff anyway.

Live long and Prosper!
Torben Nehmer

--
Torben Nehmer, Guenzburg, Bavaria, Germany
http://www.nathan-syntronics.de, mailto:torben@...
PGP Public Key: https://www.link-m.de/pgp/t.nehmer.asc

Re: Using Doxygen with Midgard

Hi,

--Jukka Zitting wrote on 2005-07-31 09:35:
> A few weeks ago I experimented with Doxygen [1] as a tool for better
> documenting and organizing the Midgard core sources. 
> 
> [...]
>
> Now that we are past 1.7, I'd like to propose adopting Doxygen or some
> other similar tool for documenting the Midgard core API and possibly
> also the PHP API.
>
> [...]

+1, definitly.

While documenting the C API is the top priority from the core perspective in my
eyes, it is as important to finally have a full, complete, up-to-date and
precise documentation of the PHP4 API of MgdSchema, the few lines we currently
have don't really help unfortunalety. And, frankly speaking, "read the source"
is the very last thing I do when it comes down to understand the PHP Midgard
API, as it is (unfortunalety) far often easier to do a quick re-implementation
on the MidCOM level then spend hours understanding the source.

Live long and Prosper!
Torben Nehmer

--
Torben Nehmer, Guenzburg, Bavaria, Germany

Re: Namespacing in the wiki

On Jul 31, 2005, at 11:21, Piotras wrote:
> 1. I created two wiki pages and they are still "not created"
> ( however content appears with direct link )
>
> 2. Why such pages are not "subpages"?
> Can we create automagically "Query Builder method" when I create
> method wiki page "under" QB?

Wiki is a flat space of documents that are identified using their  
title. The structure,
or hierarchy within a wiki comes entirely out of what is linked  
where. There can
be only one page with a particular title.

This is why namespacing is so important. I've renamed the page  
"count" to
"MidgardQueryBuilder method count" for instance, and fixed the links on:
http://www.midgard-project.org/midcom- 
permalink-7a86842cc2906de5ac0f347d8b6c734d

New pages are created by marking something on another wiki page as  
requiring
explanation, i.e. linking to it, and then clicking the link.

The problem why your links didn't work, BTW, was because of  
whitespace in them.
The linking text must be [Link target|link text], not [ Link target |  
link text ].

Re: Midgard2 again

On Jul 28, 2005, at 15:24, Piotras wrote:
> QB as a full replacement for "old" mgd_list_xxx is not the best  
> solution as it breaks
> backward compatibility. Current ,"old" midgard-php classes have own  
> sql queries
> which use date formatting etc, so QB is not able to recreate such  
> issues.

Well, we just need to add capability to QB to make such queries.

> With 1.8 we can add switch to midgard-php wchich will disable old API
> ( at least the bigger part of it ). Such solution should be used  
> only for developers and
> never on production servers.

Yep. But the mgd_xx functions should be rewritten to use MgdSchema  
and QB for
IO as soon as possible, whether they're done on C or PHP level.

> php-cli already uses it so we need rewrite config for repligard and  
> add aditional
> config "parser" for apache and keep old directives untouched.

IMO the old directives should be marked Deprecated, and datagard  
should be
changed to automatically use the new-style config when creating vhosts.

> Automated databse management should be made after libgda support,
> but we can hide libgda ( it's lack too ) in midgard-core API.

Re: Midgard2 again

Henri Bergius <henri.bergius@...> wrote:

> > QB as a full replacement for "old" mgd_list_xxx is not the best  
> > solution as it breaks
> > backward compatibility. Current ,"old" midgard-php classes have own  
> > sql queries
> > which use date formatting etc, so QB is not able to recreate such  
> > issues.
> 
> Well, we just need to add capability to QB to make such queries.

Doable , but we should define date formats for example directly in schema.
Something like : 

<property name="date" type="date" format="'%d.%m.%Y" field="created">

And then produce SQL like:

Date_format(article.created,'%d.%m.%Y') AS date

> > With 1.8 we can add switch to midgard-php wchich will disable old API
> > ( at least the bigger part of it ). Such solution should be used  
> > only for developers and
> > never on production servers.
> 
> Yep. But the mgd_xx functions should be rewritten to use MgdSchema  
> and QB for
> IO as soon as possible, whether they're done on C or PHP level.

I think,  it is already possible to rewrite almost all mgd_list_xxx.

Re: Midgard2 again

Re: Midgard2 again

Hi,

--Henri Bergius wrote on 2005-08-01 14:12:
>> Doable , but we should define date formats for example directly in schema.
>> Something like : 
>>
>> <property name="date" type="date" format="'%d.%m.%Y" field="created">
>>
>> And then produce SQL like:
>>
>> Date_format(article.created,'%d.%m.%Y') AS date
> 
> Ok, if that is the way it must be done. And if the format is not
> specified, then Unix timestamp
> could be stored.

Just a question: Do we need this really on the core level, or is it enough if
the PHP Compat layer can do it?

Live long and Prosper!
Torben Nehmer

--
Torben Nehmer, Guenzburg, Bavaria, Germany
http://www.nathan-syntronics.de, mailto:torben@...
PGP Public Key: https://www.link-m.de/pgp/t.nehmer.asc

Re: Midgard2 again

Henri Bergius <henri.bergius@...> wrote:

> > Something like :
> >
> > <property name="date" type="date" format="'%d.%m.%Y" field="created">
> >
> > And then produce SQL like:
> >
> > Date_format(article.created,'%d.%m.%Y') AS date
> 
> Ok, if that is the way it must be done. And if the format is not  
> specified, then Unix timestamp
> could be stored.

No unix timestamp. Appollo 11 was never on the moon :)

> > I think,  it is already possible to rewrite almost all mgd_list_xxx.
> 
> We need things like join queries for some mgd_list funcs.
> 
> > To make this we need to rewrite DG with PHP ( at least some parts ).
> >
> > And use simple $host->create();
> 
> Could make sense, yes. Is PHP-CLI available on most of our target  
> distros?

1.7 is not fully installable without php-cli.
( I am not sure how many midgard extension is loaded though )

Piotras

Re: Midgard2 again

Torben Nehmer <torben@...> wrote:

> >> And then produce SQL like:
> >>
> >> Date_format(article.created,'%d.%m.%Y') AS date
> > 
> > Ok, if that is the way it must be done. And if the format is not
> > specified, then Unix timestamp
> > could be stored.
> 
> Just a question: Do we need this really on the core level, or is it enough if
> the PHP Compat layer can do it?

Date type property is a nightmare from any point of view.
We can add such formatters to core , cause it is not a big problem.
However I am not sure how Date_format works with other databases.

Piotras