cdeengine-chat — A place for developers and the public to talk

Re: [CDE-chat] Development of CDE

[Andre v. Z. <an...@sp...>]

Hi Everyone

I need a show of hands, by email this time :) of who will be continuing 
to support CDE and where one will fit in.  Developers who have not 
replied to this request by the end of March 2010 will then be removed 
from the project.  Please feel free though at anytime to contact me if 
you want to help.

Areas of interest now are :

Testing cdesimple.php (The new class) with cdetestclass.php
Date handling - how should dates be handled between databases
ParseSQL - The rather large task of testing SQL translation between 
databases
Documentation

Please indicate which area above you are interested in and which 
databases you are willing to support (no more that 2 databases please)

Yours sincerely

Andre van Zuydam

-- 
Spiceware Software

------------------------------------------------------------------------
*Name:* 	Andre van Zuydam
*Email:* 	an...@sp... <mailto:an...@sp...>
*Tel:* 	087 807 8450
*Cel:* 	083 391 8443
*Fax:* 	086 682 6944
------------------------------------------------------------------------
Visit our website spiceware.co.za <http://www.spiceware.co.za/>

[CDE-chat] Update / Progress Report

[Andre v. Z. <an...@sp...>]

Hi Everyone

The Cross Database Engine has been receiving an increased number of 
downloads after being dormant for a long time which I think is also 
indicative of our activity on the engine.

The main goal of the project is to translate between dialects to 
facilitate cross database portability for PHP applications and we need 
to start brain storming how our engine will work.  So far I've only seen 
one project called SQL Fairy which actually translates database meta 
data between databases.  They do not currently handle select statements 
as far as I'm aware but we could learn something from their engine.

Another obvious reason to use our library is that developers will need 
to learn only CDE when connecting to their database of choice, and if 
they switch databases it remains the same.  We then eliminate half the 
PHP database manual !!!  It also means the challenge is up to us to 
implement as many PHP supported databases as we can. 

Future goals will be to implement other databases that PHP does not 
support like HyperTables ... who knows, nothing is impossible.

Lets start thinking about some ideas and  post them to 
cde...@li....

Thank you and keep up the good work.

Andre van Zuydam

Re: [CDE-chat] reply 4 adding method

[Andre v. Z. <an...@sp...>]

Hi Everyone

I want to see the engine developing in a manner that each developer on 
the team takes ownership of this library. 

If I see something that I particularly don't like I will mention it in 
this forum. 

If you want to add these events Ashraf, please do so and commit the 
changes and comment on them in the header of the library file and the 
rest of us will get it when we do an update on the CVS.

Andre

Linux Iraqi wrote:
> hi everyone,,,
>
> we were use to use this setters and getters in JAVA since its fully 
> Object Oriented. i guess it will be better to use setters here and 
> make the variables private rather than public; so that the CDE may be 
> developed in future to more further to be a superclass of other classes.
>
> i  also wanna add Another function for listing all the DBs that we 
> have, something like list_dbs.
> and another function for choosing my DB like select_my_db....?
>
> waiting for Andre response and suggestions from team members....
>
> Ashraf
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> cdeengine-chat mailing list
> cde...@li...
> https://lists.sourceforge.net/lists/listinfo/cdeengine-chat
>   

[CDE-chat] reply 4 adding method

[Linux I. <ira...@ya...>]

hi everyone,,,

we were use to use this setters and getters in JAVA since its fully Object Oriented. i guess it will be better to use setters here and make the variables private rather than public; so that the CDE may be developed in future to more further to be a superclass of other classes.

i  also wanna add Another function for listing all the DBs that we have, something like list_dbs.
and another function for choosing my DB like select_my_db....?

waiting for Andre response and suggestions from team members....

Ashraf



      

[CDE-chat] [CDE-Chat] Development

[Ivan C. <iv...@gm...>]

Hello everyone,

just got an idea that I'd like  to share: how about adding a method
that allows one to specify dbtype, username, password at once?
something like set_params($dbtype,$username,$password), what do you
think?

-- 
Regards,
Ivan Cat

Re: [CDE-chat] why parsing...??

[Andre v. Z. <an...@sp...>]

The Cross Database Engine is not merely a tool to connect to databases 
in one manner it really has to translate to different dialects otherwise 
an application written for MySQL won't work on SQLite.



Linux Iraqi wrote:
> Hi everybody...
>
> i was wondering WHY there is parsing since we have $dbtype....?
>
> i mean why should we parse the sql statement since the DB is specified 
> previously...?!!
>
> ashraf
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> cdeengine-chat mailing list
> cde...@li...
> https://lists.sourceforge.net/lists/listinfo/cdeengine-chat
>   

[CDE-chat] why parsing...??

[Linux I. <ira...@ya...>]

Hi everybody...

i was wondering WHY there is parsing since we have $dbtype....?

i mean why should we parse the sql statement since the DB is specified previously...?!!

ashraf



      

Re: [CDE-chat] parsesql ideas

[Lucian R. <luc...@gm...>]

Hi Andre,

  I'll start thinking on the diagram for each common instruction select,
insert, update, delete .
  Another thing, even I haven't seen till now the case when stocked
procedures (suported at least by MSSQL and MySQL starting with version 5)
used with php, we will support only execution of them. Trigers? I don't
know, may be someone will use this tool for creating a cms for database
management. Anyways we'll start with the base part and if requested some
features could be added.

Kind regards,
Lucian Rosu

On Tue, Sep 2, 2008 at 11:25 AM, Andre van Zuydam <an...@sp...>wrote:

> Hi Lucian
>
> If you and I can start working on this solution immediately it would be
> good!
>
> In firebird the expression you talked about would be implemented as
>
> select first 1000 next 500 * from table
>
> There is a little problem with where the keywords go but if we can
> create a middle ground for the sql which then can be put into any
> dialect it would be good.
>
> i.e.
>
> select first 1000 next 500 * from table = select * from table from 500
> to 1000
> select * from table limit 500, 1000 = select * from table from 500 to 1000
>
> Both statements give us the same answer in our parsesql function which
> we then translate to the applicable database with "rules" for that
> database.
>
> I think we can start by working out how different SQL queries can be
> translated into either an ANSI dialect or something we come up with to
> help get the job done
>
> Yours sincerely
>
> Andre van Zuydam
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> cdeengine-chat mailing list
> cde...@li...
> https://lists.sourceforge.net/lists/listinfo/cdeengine-chat
>

Re: [CDE-chat] parsesql ideas

[Andre v. Z. <an...@sp...>]

Hi Lucian

If you and I can start working on this solution immediately it would be 
good!

In firebird the expression you talked about would be implemented as

select first 1000 next 500 * from table

There is a little problem with where the keywords go but if we can 
create a middle ground for the sql which then can be put into any 
dialect it would be good.

i.e.

select first 1000 next 500 * from table = select * from table from 500 
to 1000
select * from table limit 500, 1000 = select * from table from 500 to 1000

Both statements give us the same answer in our parsesql function which 
we then translate to the applicable database with "rules" for that database.

I think we can start by working out how different SQL queries can be 
translated into either an ANSI dialect or something we come up with to 
help get the job done

Yours sincerely

Andre van Zuydam

Re: [CDE-chat] parsesql ideas

[Lucian R. <luc...@gm...>]

Hi everybody,

  In my opinion the array would be a very important issue, it could manage
some important situations. For instance for MySQL the top 1000 rows clause
is
        select * from table LIMIT 0, 1000
 But parsing the next query
        select * from table LIMIT 500, 1000   -- selection of top 1000
records starting with the 501th record
from MySQL to MSSQL cannot be made directly but using some artificial
solutions, and one of them could be an array.
Hope you understand what I'm talking about. If not, waiting for questions.

Related to parsing function, I believe that each of us who has some more
experience in a database type could work on a part of it.
But first we need to create a logic scheme (diagram) for the parsing issue.
After the logic diagram is created and can be applied on any database type,
we can find the middle solution for parsing between different databases
type.

If nobody can manage this, I guess I could do some work on this, but that
only if in case that nobody has experience in this kind of issues.

All the best,
Lucian Rosu

[CDE-chat] parsesql ideas

[Andre v. Z. <an...@sp...>]

Hi Everyone

I was just thinking about the parsesql function.  Could we not maintain 
an array of dialect keywords and their counterparts to reference in the 
parsesql function ?

Example:

array["1000"]["firebird"] = "top";
array["1000"]["firebird"] = "first";
array["1000"]["oracle"] = "rownum";

The 1000 is merely a numeric reference or id we can associate with the 
keyword.

select first 10 * from table

would become

select 1000 * from table

which could then be replaced by the necessary keywords for the 
applicable database.

the oracle query would become

select * from table where 1000 < 10

Anyway - the above needs work but who thinks its worth following?

[CDE-chat] CDE Update

[Andre v. Z. <an...@sp...>]

Hi Everyone

Lucian is going to help with MSSQL or MySQL and perhaps Oracle ? but 
this does not mean that we cannot all contribute to each different type 
of database.  I would just like one person to take charge of each 
different type of database.  This means if we get bug requests or 
feature requests for a particular database the person responsible will 
handle it and make sure it gets done.

The documentation for CDE is currently hosted on 
http://www.spiceware.co.za/cde and is available under CVS.  If we can 
finish the basic skeleton of this before we make another release it will 
be good.
I stopped at blob_read !   If we implement blob read then it would be 
good to have the functionality for blobs complete for all the databases.

Thank you everyone for your excitement and keep up the good ideas!

Yours sincerely

Andre van Zuydam

[CDE-chat] For Lucian

[Andre v. Z. <an...@sp...>]

Hi Lucian

I've definitely responded to all your emails, if you're reading this 
then perhaps there is a communication problem between source forge and 
your email account ?

Otherwise we must find another way to get in touch with you.  If you can 
register on this list then we should be fine.

Thank you

Andre

Re: [CDE-chat] parsing...

[Andre v. Z. <an...@sp...>]

Yes, it is the translation of the different SQL statements between 
database dialects.
We must aim to conform to an ANSI compliancy.

Have a look at the parsesql function to get an idea of what its about.

An easy example is: [top] in access is [first] in firebird.

Example:  I wrote a simple application in access to get the top ten 
users of a website but now someone wants to run it on a Firebird 
database, I say no problem because I know that the engine support cross 
database coding.

Here is my query in access:

select top 10 * from webusers

Now the CDE engine realises that the connection is to a Firebird 
database so it needs to check that the keywords from other database 
systems get the same results.
Running parsesql on the above query will return: select first 10 * from 
webusers which then gets used in the query.

I hope this is clear, let me know if I must explain some more.



Linux Iraqi wrote:
> hi andre and everyone...
>
> about parsing...
>
> is it means about formating* the sql statement ...?
> like here
>
> http://www.wangz.net/cgi-bin/pp/gsqlparser/sqlpp/sqlformat.tpl
>
> or its something else...?
>
> ashraf
>
>
> * coloring - separating sql by lines - capitalizing keywords... etc.
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> cdeengine-chat mailing list
> cde...@li...
> https://lists.sourceforge.net/lists/listinfo/cdeengine-chat
>   

[CDE-chat] parsing...

[Linux I. <ira...@ya...>]

hi andre and everyone...

about parsing...

is it means about formating* the sql statement ...? 
like here

http://www.wangz.net/cgi-bin/pp/gsqlparser/sqlpp/sqlformat.tpl

or its something else...?

ashraf


* coloring - separating sql by lines - capitalizing keywords... etc.



      

[Cdeengine-chat] Inital Welcome & Tasking for the Cross Database Engine Team

[Andre v. Z. <an...@sp...>]

Welcome everyone, currently we're a team of 5 and here is how I propose 
we forward the project.

I will be leading the development and help test what everyone is busy 
developing.

Ivan Cat will be heading up the PostGres development  & functionality 
and helping with the releases of the project

Ashraf will be heading up the MySQL development & functionality

Wimpie Vermaak will be doing the SQLite development & functionality

Lukskywalker will be helping out on MSSQL ?

To summarize:

The Cross Database Engine is fairly easy to implement when it comes to 
adding other databases, however this is not the main aim of the project.
The main aim will remain to create or interpret between the different 
database environments so that Developer A developing in Database B with
CDE can safely run his application on Database C without changing his 
code and this means his SQL either.

Our current areas of need are as follows:

1. The various PHP databases need to be encapsulated which is happening 
rather rapidly.
2. The parsesql functionality needs to be discussed and a plan must be 
thought out about how this can work efficiently (this translates the SQL)
3. Blob / Clob / Binary object support needs to be completed for each 
database environment, I've done it for Firebird but do not know how
    it works for the rest.
4. Each area where there is functionality lacking for a particular 
database it needs to be added. For instance Firebird had no support for 
numrows so I added it.
5. There is a new file in the CVS which is called cdetestclass.php which 
I'm going to add some routines to which should work on your database 
environments,
   if they do not work then there is some work to be done in the 
parsesql for the particular environment. (The initial database is SQLite 
which will port to the others)
   Ideas are welcome here about how to test from PostGres to Firebird 
etc ...
6. Date handling is quite a bother between databases, some stuff I test 
in SQLite works but doesn't work in Firebird & MSSQL hence the tran_date 
function, however
    I still have problems with it.
7. Use this list as a forum for sharing information as the public can 
use it as a reference also.

And thats about it for now, lets see if we can tackle these issues and 
work to testing with the cdetestclass.php which will become our standard 
benchmark.

I welcome any ideas to ensure the success of this project and remember 
our work needs to be good as developers will be putting their faith in 
our engine.

Yours sincerely

Andre van Zuydam





 

[Cdeengine-chat] e-mail

[Linux I. <ira...@ya...>]

ira...@ya...


      

[Cdeengine-chat] e-mail

[Linux I. <ira...@ya...>]

ira...@ya...


      

[Cdeengine-chat] Welcome to CDE

[Andre v. Z. <an...@sp...>]

Welcome to the Cross Database Engine.  In this email forum I wish to 
help answer questions as well as to assist where possible in making the 
implementation of the Cross Database Engine in PHP as simple as possible.

Yours sincerely

Andre van Zuydam