This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit

eZ Community » Forums » Suggestions » Give projects some love

Give projects some love

Give projects some love

Friday 09 November 2007 7:23:50 am - 13 replies

Following Tony's cry.

Same needs applies, and most of the suggestions about contrib can apply on projects as well, after the merge (next week ?).


Friday 09 November 2007 10:42:59 am

Should we ask eZ to provide an activity list e.g:


Friday 09 November 2007 11:07:22 am


That is a great idea Paul, I second the idea.

With a little more notice on which projects are most active.

This might just increase activity on projects through friendly competition happy.gif Emoticon


Friday 09 November 2007 11:14:42 am

Added as an enhancement:

Friday 09 November 2007 4:10:33 pm

One other thing that would be nice: have extensions to specify their db compatibility besides the ususal ez version.

As most extension developers likely not very interested in this, it could be made a mandatory attribute:
N/A - no db needed

btw: Filed under bug id #011883

Friday 09 November 2007 6:07:02 pm


Lets spread the Lurve!

Sunday 11 November 2007 8:13:07 pm

<i>@Gaetano Giunta</i>

We were under the impression that the design of the eZ Publish would free most extensions from general database specific requirements.

eZ Publish already provides detailed requirements for databases (and versions) which may be used such as MySQL, Oracle, PostgreSQL.

eZ Publish extensions traditionally make use of the database abstracted through eZ Publish.

So unless your greatly pushing beyond standard use of eZ Publish the 'db compatibility' requirements are specified by eZ Publish so asking each extension to document this detail seems to me to be a trivial notion of duplication only bound to introduce further confusion rather than reduce it.

Certainly extensions which do truly have specific requirements should indeed document these unique requirements, yet for almost all extensions currently this is not necessary or applicable (IMHO).


Blink 182 - I Miss You | Gwen Stephani - Whatcha Waiting For | Kanye West - Stronger ...</i>

Modified on Sunday 11 November 2007 8:15:26 pm by // kracker

Sunday 11 November 2007 9:49:36 pm

Sorry, but this is just wishful thinking.
To do real cross-database development there are about a thousand abstractions that the library in us must provide, eg:
- a string concatenation operator
- a string escaping function
- some functions/schemas to define tables, indexes and sequences
- datetime functions

the ez db lib provides most of those (except for the datetime stuff, since times are treated as integers), BUT... soon as you are allowed to write SQL in your code, you have huge chances of breaking some database.
The most basic example being: "SELECT NAME FROM EMP AS E, ..."
The "as" for table names is ok with postgres and mysql, but it is a fault with oracle.
If you start looking at native string manipulation functions or, worse, bit manipulation functions, you will find that different databases have different function names.

So the careless developer, wh coded his extensions and relased to the community without ever getting paid for proper testing and docs, is likely to never have tested his code with oracle, and compatibility is far from being guaranteed.

Sunday 11 November 2007 10:44:31 pm

I <i>challenge</i> Gaetano to cite at least five existing eZ Publish extensions which are affected by this problem. Developers are supposed to use the API and -not- write sql directly.

Sunday 11 November 2007 11:20:48 pm

Hey guys, take it eZ.

I never said that I know for a fact that any single given extension is not compatible with Oracle or Postgres. In fact, I would be very happy to find out that it is not the case.

But I ran a quick grep for "arrayquery" on my harddisk and found sql embedded in:
(note: not "wrong" sql, just plain sql)

I have not at the moment a full svn copy of all the community contributions, but my educated guess is that at least some of those do manipulate sql queries.

Monday 12 November 2007 11:25:20 am

I think Gaetano has a good point. Certified extensions cost more when the db is 'touched' and by clarifying when the api is not used for db access it will be very clear what the risk is with an extension.

The automated approval tool should be able to work this all out to be honest which would make auto-generation of stats a doddle.


Thursday 15 November 2007 12:07:45 am

Mummy: All extensions that need some extra database table needs to do this, and I don't think that will improve much before we switch to persistantObject from eZ Components (but even then you will always have edge cases)

Gaetano Giunta: isn't 'as' a fairly standard sql functionality, do they have support for it in more recent versions? How do you normally do queries on oracle where you need to relate to 1 table several times?

Maybe a tested on / certified for: mysql/pgsql/mssql/oracle thingy??

Modified on Thursday 15 November 2007 12:09:14 am by André R

Thursday 15 November 2007 9:14:07 am

<i>isn't 'as' a fairly standard sql functionality, do they have support for it in more recent versions? How do you normally do queries on oracle where you need to relate to 1 table several times?</i>

SELECT ... FROM TABLE1 T1, TABLE2 T2, etc...

this is supported on all other rdbms, so it is really a no brainer.
AS is still supported (and needed) to alias names of select items

Tuesday 20 January 2009 8:43:35 am

hi guys,

The above article is nice. I know little bit about it. I want to know more about it. Thanks


From Tony: If this is not Spam let me know. Otherwise it will be deleted.

Modified on Tuesday 20 January 2009 8:53:02 am by shekhar sarkar


You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from