pg-nuke-devel Mailing List for PG-Nuke
Brought to you by:
mazzabr
Menu
▾
▴
pg-nuke-devel — Just for developers
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(26) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <ben...@id...> - 2004-05-22 13:23:14
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: <pg...@rv...> - 2003-06-01 00:20:35
|
Hey Mazza, how is your headage currenty?? I haven't done any work on the rewrite the last few they because I have been working on my boot. Did you alreday found wy it is the $id thingy changed in the source files?? Or chould I commit the origional nuke code to the tree. and have you seen what fb did on the nuke site??? have lots of nuke fun, RIes |
|
From: <rv...@dd...> - 2003-05-30 07:13:59
|
> > > > -------------------- > Looking for a better .sig. Suggestions are being accepted. > > On Fri, 30 May 2003 rv...@dd... wrote: > > !Hey Payam, > > (...) > > !The good thing is that we can easely upgrade to a higher nuke version > because > !we only have ONE file to test... > !The bad part is that the rewriter code will consume some processor time. On > my > !machine (PII 233Mhz) it currently takes arounf 250ms to rewrite 144 SQL > !statements. > > That's where we had to choose, the first option, propoused by Ries is the > rewriter, much more pratice and efficient, although it has some > performance issues. > > The other option was a set of scripts, probably perl, that would rewrite > each query, which wouldn't be that efficient and wouldn't be very > pratical. But it would give us a better performance. > > The solution until now is the query cache. (Ries correct me if I > understood it wrong) Correct.. > > If you take a look there are plenty of queries that do exactly the same > thing, so we can cache them and expect a better performance. And that's > the main issue that we are trying to get better and better. Partly right... I did query the DBA a lot because I some cases (inserts quertys) I need to find out which field is a serialfield. That query to the backend is rather complex and takes a lot of extra time because you need to talk to the backend twice for each single query. Currenty I cache these querys, not the querys nuke generates.. > > I had another idea, we could have two levels of cache. The first would > have a per page scope, being valid only in a given page. Another would be > valid for all generated page for a given period of time. Both together > shall give us a even better performance. mazza, what do you want to cache here?? 1) The sql itself 2) The result of the SQL? If you think about option 1...I'm thinking about this to. One idea is to create a MD5 for each query and store the result of it in a cache. Then when a new query comes in it first checks the query cache and only when it's not in it does the rewriter thing or else it retreivers the new query from the cache. BTW: most of the sql querys are select querys and I already did some optimalisation on them. If you think about option 2 I would so..no don't do that becasue you would comprimse the idea of a database backend. Appart from that it takes a huge a lot of memory per session. > > But let's take a look at our target market. Corporations usually have > DBAs that are able to optimize PostgreSQL so the have a better > performance, even though we must enhance performance as much as we can. > > mazza. > > ! > ! > !Hope this clearifies... > ! > !Ries > ! > ! > ! > ! > ! > !Citeren Payam bahraini <p_b...@ya...>: > ! > !> Hi all, > !> > !> I'm a newbie and so idon't know what is a rewriter and > !> why it is necessary? > !> > !> Tnx > !> > !> Payam > !> > !> __________________________________ > !> Do you Yahoo!? > !> Yahoo! Calendar - Free online calendar with sync to Outlook(TM). > !> http://calendar.yahoo.com > !> > !> > !> ------------------------------------------------------- > !> This SF.net email is sponsored by: eBay > !> Get office equipment for less on eBay! > !> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > !> _______________________________________________ > !> PG-nuke-devel mailing list > !> PG-...@li... > !> https://lists.sourceforge.net/lists/listinfo/pg-nuke-devel > !> > !> > ! > ! > ! > ! > ! > !------------------------------------------------------- > !This SF.net email is sponsored by: eBay > !Get office equipment for less on eBay! > !http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > !_______________________________________________ > !PG-nuke-devel mailing list > !PG-...@li... > !https://lists.sourceforge.net/lists/listinfo/pg-nuke-devel > ! > > > > ------------------------------------------------------- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay! > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > PG-nuke-devel mailing list > PG-...@li... > https://lists.sourceforge.net/lists/listinfo/pg-nuke-devel > > |
|
From: Fabio A M. <ma...@al...> - 2003-05-30 03:11:48
|
-------------------- Looking for a better .sig. Suggestions are being accepted. On Fri, 30 May 2003 rv...@dd... wrote: !Hey Payam, (...) !The good thing is that we can easely upgrade to a higher nuke version because !we only have ONE file to test... !The bad part is that the rewriter code will consume some processor time. On my !machine (PII 233Mhz) it currently takes arounf 250ms to rewrite 144 SQL !statements. That's where we had to choose, the first option, propoused by Ries is the rewriter, much more pratice and efficient, although it has some performance issues. The other option was a set of scripts, probably perl, that would rewrite each query, which wouldn't be that efficient and wouldn't be very pratical. But it would give us a better performance. The solution until now is the query cache. (Ries correct me if I understood it wrong) If you take a look there are plenty of queries that do exactly the same thing, so we can cache them and expect a better performance. And that's the main issue that we are trying to get better and better. I had another idea, we could have two levels of cache. The first would have a per page scope, being valid only in a given page. Another would be valid for all generated page for a given period of time. Both together shall give us a even better performance. But let's take a look at our target market. Corporations usually have DBAs that are able to optimize PostgreSQL so the have a better performance, even though we must enhance performance as much as we can. mazza. ! ! !Hope this clearifies... ! !Ries ! ! ! ! ! !Citeren Payam bahraini <p_b...@ya...>: ! !> Hi all, !> !> I'm a newbie and so idon't know what is a rewriter and !> why it is necessary? !> !> Tnx !> !> Payam !> !> __________________________________ !> Do you Yahoo!? !> Yahoo! Calendar - Free online calendar with sync to Outlook(TM). !> http://calendar.yahoo.com !> !> !> ------------------------------------------------------- !> This SF.net email is sponsored by: eBay !> Get office equipment for less on eBay! !> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 !> _______________________________________________ !> PG-nuke-devel mailing list !> PG-...@li... !> https://lists.sourceforge.net/lists/listinfo/pg-nuke-devel !> !> ! ! ! ! ! !------------------------------------------------------- !This SF.net email is sponsored by: eBay !Get office equipment for less on eBay! !http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 !_______________________________________________ !PG-nuke-devel mailing list !PG-...@li... !https://lists.sourceforge.net/lists/listinfo/pg-nuke-devel ! |
|
From: <rv...@dd...> - 2003-05-29 22:30:05
|
Hey Payam,
the rewriter code analyzes the SQL generated by nuke and rewrites the SQL to
something that postgresql will understand, or does not give any error on.
example:
CREATE TABLE test (
id SERIAL,
value TEXT
)
Now in MySQL this is possible:
INSERT INTO test VALUES (NULL, 'Ries van Twisk');
The above SQL is not a valid SQL because the SERIAL field is a autonummering
field the as a 'NOT NULL' constraint and as you can see MySQ:L allows us to
insert a NULL in that field which is bad bad bad, It's not even valid in any
SQL language...
The rewriter we are talking about analyses the SQL and automaticle generates
something like this:
INSERT INTO test (value) VALUES ('Ries van Twisk');
As you can see the NULL insert is removed...and this IS valid for ANY db.
It also solvses some other problems aswell which has something to do with
invalid dates, case-sensitifity in a PHP/MySQL environments, Invalid usesage of
a double quoute ", invalid usage of the char type.
The good thing is that we can easely upgrade to a higher nuke version because
we only have ONE file to test...
The bad part is that the rewriter code will consume some processor time. On my
machine (PII 233Mhz) it currently takes arounf 250ms to rewrite 144 SQL
statements.
Hope this clearifies...
Ries
Citeren Payam bahraini <p_b...@ya...>:
> Hi all,
>
> I'm a newbie and so idon't know what is a rewriter and
> why it is necessary?
>
> Tnx
>
> Payam
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
> http://calendar.yahoo.com
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> PG-nuke-devel mailing list
> PG-...@li...
> https://lists.sourceforge.net/lists/listinfo/pg-nuke-devel
>
>
|
|
From: Payam b. <p_b...@ya...> - 2003-05-29 20:45:49
|
Hi all, I'm a newbie and so idon't know what is a rewriter and why it is necessary? Tnx Payam __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com |
|
From: <rv...@dd...> - 2003-05-29 06:34:03
|
Hey Guys/Garls, this is just a test mail... I forgot to subscribe to the nuke-devel lijst...hahahah I stupid can I be..... You all have fun!!! Ries |
|
From: Fabio A M. <ma...@al...> - 2003-05-29 02:31:53
|
Mark: (Cc to devel mailing list, hope you don't mind) (see comments bellow) -------------------- Looking for a better .sig. Suggestions are being accepted. On Wed, 28 May 2003, Mark Fitzgerald wrote: !Fabio A Mazzarino wrote: ! !> Mark: !> !> About contacting FB. This is an old story, Ries and I have already tried !>to contact him, not just us, but the whole China population too, but !>without success. !> !> FB has a wrong conception about Free Software. He only accepts voluteers !>if he gets paid (US$ 10 for developer), for me it sounds absurd, paying !>for volunteer in someone other project? Not only this, he doesn't stop !>insisting that GPL'ed web sites must keep the copyright message, that's !>absurd. !> !In addition, he holds copyright to all images on his site, including the !bomb. This means at the very least I need to sketch a new bomb (if I !use a bomb) in the logo for PG-Nuke. I don't think that the bomb would be nice :o/ Too violent :o) ! !> This added to the lack of support to PostgreSQL (BTW PHP-Nuke says that !>supports PostgreSQL, but it doesn't), took us to this project. !> !> I tried to consult him in order to have his support and even to add !>pg-nuke to his own CVS tree, which is not public. But he doesn't even !>answer to my messages. !> !> But PHP-Nuke is such a good idea and has many plugins and add-ons, so we !>decided not to fork, but to branch PHP-Nuke, and that's what we are doing !>here. ;o) !> !Fair enough. Have you read postnuke.com, or geeklog.net? Have you !talked to their developers, and/or considered getting involved with !those projects instead of creating PG-Nuke? Geeklog.net seems rather !open, but postnuke.com seems fairly closed. Well, I've took a look to postnuke, and they want to be a fork, that's what we don't want to. We want full compatibility with PHP-Nuke, all we want is a PostgreSQL port, nothing more. I'll take a look to geeklog ASAP ! !> We don't intend to be a completely independente project, although we !>don't agree with some FB's directions we still are just a branch (maybe !>we'll become a fork in the future, but not for now) !> !I now see why you disagree with his approach. ! !> About this message_die() error. It doesn't seems to be a PHP function, so !>it's a PHP-Nuke function. We need to know where it is declared, so we can !>determine where is the problem. !> !> If it's a SF (Source Forge) error, that's easy to fix, SF support is very !>efficient, and they're very proud in receiving bug reports like this. ITOH !>if it's a PHP-Nuke I think that wc must fix by ourselves and hope that FB !>listen to us and accept the bug fix. (unffortunetly that's the way it is) !> !Sounds good. I'll need to see the code in order to know how to fix it, !though. ! !>Well, let me see your logo propostion ;o) !> !>mazza. !> !I've just completed another couple of hours of research and playing out !of ideas. Preparing a quality sketch will take another couple of hours, !so I want to know a little more before I proceed. First, I need to know !if you want to possibly be related to the two other projects (postnuke, !geeklog) I mentioned above. ! !With regards to ideas, I could include ! ! * the bomb image; Too violent, but will be directly connected to PHP-Nuke ! * the php logo/image; That would be nice, they do a very hard work and deserve credits. ! * some nuclear imagery (preferably positive, such as a nuclear atom ! sketch, or a nuclear smokestack), and, of course; That sounds good, but we cannot be fixed in this, Nuke is just a legacy from the original project. ! * elephants (probably african, but we can use asian if you like (see ! images.google.com for examples - asian have smaller ears and ! larger eyes)). I like elephants, although you are the one who knows better about design. ! !Seeing as the 'nuke' term has no meaningful history, I would prefer to !not include it in the logo at all; rather, we could have some imagery of !a CMS (content management system), such as bookshelves, libraries, open !books, computer disks, et cetera. But, of course, that depends somewhat !on your answers to the question about postnuke and geeklog. ! !Sorry if I sound like I'm stalling, but I want to do a good job, and !would prefer to only do it once. :*) Huge revolutions happens slowly. ! !Mark !p.s. Yes, I do in fact have some pencil sketches at this point; I !haven't been just thinking. !p.p.s. Is it okay if I license the logo under GPL? I'm not sure, but I think that there's another FSF license to be applied in this case. mazza. |
|
From: Fabio A M. <ma...@al...> - 2003-05-29 02:23:03
|
Ries: IMO memory consumption is not an issue, I think that we can use a little bit more memory in the name of performance (which IMO might become critical when using PHP). 32 KB/session I think that is acceptable, mainly because we are focusing corporate using. They'd prefer to spend a little bit more in memory, which is cheap now a days, then to have a slower service. For me Session is ok. And IMO it's a better solution, more elegant and more simple. mazza. -------------------- Looking for a better .sig. Suggestions are being accepted. On Tue, 27 May 2003 rv...@dd... wrote: !Mazza, ! !instead of using a shared memoryblock or a shared memory file. I can !also use a session ($_SESSION[...]) but the tradeoff is that PHP will !consume more memory. This is around 32Kb per session. But the good part !is that it is around 300% faster then useing a shared memory buffer !(shmop functions). ! !what do you think??? ! ! !Ries ! ! ! ! !------------------------------------------------------- !This SF.net email is sponsored by: ObjectStore. !If flattening out C++ or Java code to make your application fit in a !relational database is painful, don't do it! Check out ObjectStore. !Now part of Progress Software. http://www.objectstore.net/sourceforge !_______________________________________________ !Pg-nuke-devel mailing list !Pg-...@li... !https://lists.sourceforge.net/lists/listinfo/pg-nuke-devel ! |
|
From: Fabio A M. <ma...@al...> - 2003-05-28 03:36:10
|
Ries: First, try to avoid sending a copy to me. I'll also try to change the reply-to field (unffortunely I've lost my password) comments bellow... -------------------- Looking for a better .sig. Suggestions are being accepted. On Tue, 27 May 2003 rv...@dd... wrote: !Hey Maza, ! !here is a other update. ! !I'm currently doing a little rewrite of the rewriter code to make it easer to !understand. This is still w.i.p. Comments are not just welcome, they are really needed. ! !I also modified my test.php file so I can measure rewrite times on SQL so when !I modify some code I can see if the performance is better or worse.. ! !Currently for the index.php page php-nuke generates around 137 SQL !querys which takes up to 2200ms to process on the rewriter (shared !memory cache). This is on my 230Mhz test server. ! !TO compare: Without the cache code it takes around 8200ms !TO compare: With the file cache on instead of a shared memory cache it takes !around 1500ms. maybe it's because the shared memory is more processing costful then disk memory cache, probably some protocol needed to be followed. So if you use a cache-less disk system we'll probably have a worse performance. ! !Funny isn't it?? filecache is faster then a shared memory cache!!!! Not !sure wy but I do some extended testing on this... ! !I'll investigate and lett you know. It's probably answered. ! !I'll commit the test.php code as soon it's ready to the tools tree/branch. tool tree, that's good. ;o) ! !have fun!!! ! !Ries ! ! ! ! !------------------------------------------------------- !This SF.net email is sponsored by: ObjectStore. !If flattening out C++ or Java code to make your application fit in a !relational database is painful, don't do it! Check out ObjectStore. !Now part of Progress Software. http://www.objectstore.net/sourceforge !_______________________________________________ !Pg-nuke-devel mailing list !Pg-...@li... !https://lists.sourceforge.net/lists/listinfo/pg-nuke-devel ! |
|
From: <rv...@dd...> - 2003-05-27 21:56:24
|
Mazza, instead of using a shared memoryblock or a shared memory file. I can also use a session ($_SESSION[...]) but the tradeoff is that PHP will consume more memory. This is around 32Kb per session. But the good part is that it is around 300% faster then useing a shared memory buffer (shmop functions). what do you think??? Ries |
|
From: <rv...@dd...> - 2003-05-27 21:04:52
|
Hey Maza, here is a other update. I'm currently doing a little rewrite of the rewriter code to make it easer to understand. This is still w.i.p. I also modified my test.php file so I can measure rewrite times on SQL so when I modify some code I can see if the performance is better or worse.. Currently for the index.php page php-nuke generates around 137 SQL querys which takes up to 2200ms to process on the rewriter (shared memory cache). This is on my 230Mhz test server. TO compare: Without the cache code it takes around 8200ms TO compare: With the file cache on instead of a shared memory cache it takes around 1500ms. Funny isn't it?? filecache is faster then a shared memory cache!!!! Not sure wy but I do some extended testing on this... I'll investigate and lett you know. I'll commit the test.php code as soon it's ready to the tools tree/branch. have fun!!! Ries |
|
From: Fabio A M. <ma...@al...> - 2003-05-27 12:19:52
|
Mark: About contacting FB. This is an old story, Ries and I have already tried to contact him, not just us, but the whole China population too, but without success. FB has a wrong conception about Free Software. He only accepts voluteers if he gets paid (US$ 10 for developer), for me it sounds absurd, paying for volunteer in someone other project? Not only this, he doesn't stop insisting that GPL'ed web sites must keep the copyright message, that's absurd. This added to the lack of support to PostgreSQL (BTW PHP-Nuke says that supports PostgreSQL, but it doesn't), took us to this project. I tried to consult him in order to have his support and even to add pg-nuke to his own CVS tree, which is not public. But he doesn't even answer to my messages. But PHP-Nuke is such a good idea and has many plugins and add-ons, so we decided not to fork, but to branch PHP-Nuke, and that's what we are doing here. ;o) We don't intend to be a completely independente project, although we don't agree with some FB's directions we still are just a branch (maybe we'll become a fork in the future, but not for now) About this message_die() error. It doesn't seems to be a PHP function, so it's a PHP-Nuke function. We need to know where it is declared, so we can determine where is the problem. If it's a SF (Source Forge) error, that's easy to fix, SF support is very efficient, and they're very proud in receiving bug reports like this. ITOH if it's a PHP-Nuke I think that wc must fix by ourselves and hope that FB listen to us and accept the bug fix. (unffortunetly that's the way it is) Well, let me see your logo propostion ;o) mazza. -------------------- Looking for a better .sig. Suggestions are being accepted. On Tue, 27 May 2003, Mark Fitzgerald wrote: !Fabio A Mazzarino wrote: ! !> Mark: !> !> have you ever seen a problem like this? I don't know what is happening. !> !> Well I can give access to you, but I still don't know how to give access !>to you. I'll take a look into options. For now I can have your SF alias. !> !Let me know what you can work out. I just did some reading !(http://www.phpbb.com/phpBB/viewtopic.php?t=70953); my guess is that !it's a simple bug in the PHP code for your current web site. ! !>Let me take a look at your logos ideas. I'm sure you'll have great ideas !>(I think that something about elephants will be nice) !> !>Let's go. !> !>mazza. !> !I've been doing research and working on some ideas for the past hour or !two. Have you tried talking to Francisco Burzi about the PostgreSQL !problems you see in PHP-Nuke? ! !I'll forward you some images once I've done some more work. Perhaps !tomorrow sometime. (I'm in eastern Canada - GMT-4; how about you?) ! !Mark ! |
|
From: Fabio A M. <ma...@al...> - 2003-05-27 12:02:21
|
Ries: when sync the CVS don't forget to keep directory names, it's important to apply your patches util I write some steps to update and commit cvs. mazza. -------------------- Looking for a better .sig. Suggestions are being accepted. On Tue, 27 May 2003 rv...@dd... wrote: !Citeren Fabio A Mazzarino <ma...@al...>: ! !> !> I'll take a look at the original nuke.sql and try to find out if there's !> any database entry that's case sensitive. !I think not.... That is what the rewriter should solve. Case sensitive is only !a problem when nuke does a SELECT query and the rewriter does already takes !care of that wel....it should take care of that..... ! !If you find something...just lett me know. ! !I'll sync with the CVS somewhere this day. ! !RIes !> !> Maybe another entry at fields_equiv.php solves the problem. !> !> I'll try to take a look. !> !> mazza. !> !> -------------------- !> Looking for a better .sig. Suggestions are being accepted. !> !> On Mon, 26 May 2003 rv...@dd... wrote: !> !> !One more thing, !> ! !> !currently I have trubles iwth the download module if nuke...I'm working on !> it.. !> !It seems that I can add dowloads but for some reason it does not display !> them.. !> ! !> ! !> !RIes !> ! !> !> ! ! ! ! ! !------------------------------------------------------- !This SF.net email is sponsored by: ObjectStore. !If flattening out C++ or Java code to make your application fit in a !relational database is painful, don't do it! Check out ObjectStore. !Now part of Progress Software. http://www.objectstore.net/sourceforge !_______________________________________________ !Pg-nuke-devel mailing list !Pg-...@li... !https://lists.sourceforge.net/lists/listinfo/pg-nuke-devel ! |
|
From: <rv...@dd...> - 2003-05-27 04:43:53
|
Citeren Fabio A Mazzarino <ma...@al...>: > > I'll take a look at the original nuke.sql and try to find out if there's > any database entry that's case sensitive. I think not.... That is what the rewriter should solve. Case sensitive is only a problem when nuke does a SELECT query and the rewriter does already takes care of that wel....it should take care of that..... If you find something...just lett me know. I'll sync with the CVS somewhere this day. RIes > > Maybe another entry at fields_equiv.php solves the problem. > > I'll try to take a look. > > mazza. > > -------------------- > Looking for a better .sig. Suggestions are being accepted. > > On Mon, 26 May 2003 rv...@dd... wrote: > > !One more thing, > ! > !currently I have trubles iwth the download module if nuke...I'm working on > it.. > !It seems that I can add dowloads but for some reason it does not display > them.. > ! > ! > !RIes > ! > > |
|
From: Fabio A M. <ma...@al...> - 2003-05-27 03:44:19
|
Ries: I'm sending this message to you AND to pg-nuke-devel list, so we can starting comunicating the right way (with participation of everyone). I have sent to the list our lasts discussions about pg-nuke so most people can understant what is happening through the mailing list history. -------------------- Looking for a better .sig. Suggestions are being accepted. On Mon, 26 May 2003 rv...@dd... wrote: !> !> Ries: !> !> Are you ok if I send three tester to your sample site? !Sure, as long as they don't try to hack the machine.. I haven't done anything !on security the last few months.. ! !> I'm only sorry to tell that unfortunetly SF can't provide us a place !>to !> test our project (they don't support PostgreSQL). ! !But I think that !I can redirect a sub-domain to your site, I'm not sure, but I'll !verify. Do they support PHP4??? If so we can host it on SF and use my !PostgreSQL server as the DB backend. Don't even try to do this. Cross-server database across the internet is too problematic, we'll have problems with response time, speed, CPU load, net traffic, and stability. I can even imagine that SF team won't be happy with such bad utilization of the resouces. I see no problem in using PHP-Nuke to our comunity site, and as soon as we can have a PHP+PostgreSQL server avaiable exclusively for testers I think that we won't have a problem. So, IMO, we can keep things the way they are now. Don't forget, for now we are just a branch, not a fork. ;o) mazza. ! !> !> What do you think? !I think we have a project going on!!! :-) ! !> !> mazza. ! Ries ! !> !> -------------------- !> Looking for a better .sig. Suggestions are being accepted. !> !> On Sun, 25 May 2003 rv...@dd... wrote: !> !> ! !> ! !> !Hey Fabio, !> ! !> !how are you these days? Hopefully your headage didn't stayed to long last !> week. !> ! !> !In the mean time I have added a SQL cach to the code so it releases the !> backend !> !from the SQL calls I make, I also found a little bug in the sql_explode !> !function. Aparently a '' is the escape code for ' in MySQL and I splitted !> the !> !string on such a double quote. I'm currently not sure what happens with !> more !> !quotes.... !> ! !> !It seems the webpages are generated about twice as fast then without the !> cache !> !code. I mode it so that it can use shared memory when available but i !> coulnd't !> !make it to work yet... !> ! !> !Ries !> ! !> !> ! ! ! |
|
From: Fabio A M. <ma...@al...> - 2003-05-27 03:38:04
|
--------------------
Looking for a better .sig. Suggestions are being accepted.
---------- Forwarded message ----------
Date: Thu, 22 May 2003 09:43:53 +0200
From: rv...@dd...
To: Fabio A Mazzarino <ma...@al...>
Subject: Re: Current status...
Fabio,
here you find the a diff.
You can patch it agains the origional PHP-Nuke source using:
patch -Np1 < PHP-nuke-6.5-pg.diff
It includes the rewriter and my nuke-pg.sql.
Ries
Citeren Fabio A Mazzarino <ma...@al...>:
>
> (comments below...)
>
> sorry if I'm answering too short, I'm in a flew. :o'P
>
> --------------------
> Looking for a better .sig. Suggestions are being accepted.
>
> On Wed, 21 May 2003 rv...@dd... wrote:
>
> !Citeren Fabio A Mazzarino <ma...@al...>:
> !
> !Hey Fabio,
> !
> !See comments between below.
> !
> !Here is my site's IP again with my new code, I didn't test all modules but
> I
> !didn't fine any anomalys so far, Currently I do a debug level 3 on
> postgreSQL
> !to see what and where it goes wrong: http://213.73.163.64:8080
>
> I'll take look, as soon as my headache stops.
>
> !
> !I see I'm a developer now... would you like me to add my code so you can
> se
> !what I'm doing and how it works???
>
> send me a tarball, I'll proudly set it up to you, and also take a look at
> you wonderful ideas ;o')
>
> !
> !regards,
> !Ries van Twisk
> !
> !
> !>
> !> let's see... (hmmm.. interesting... :o)
> !>
> !> --------------------
> !> Looking for a better .sig. Suggestions are being accepted.
> !>
> !> On Tue, 20 May 2003 rv...@dd... wrote:
> !>
> !> !Fabio,
> !> !
> !> !
> !> !one question about case sensitivity, do your run windows on your
> !> !apache/php machine or do you have a all *nix situation?? I believe, if
> I
> !> !rememeber correctly that PHP4 is NOT case sensitive on a windows
> !> !platform. I think that postgreSQL on windows runs onder cygwin so the
> !> !behafure is the same omn *nix or windows. For your information my test
> !> !machine is a P233/3x4Gb HD/128MB ram/Debian Woody/PHP4/Apache
> !> !1.3.x/PostgreSQL 7.2.x
> !>
> !> Now I remember this feature, I solved this in a very clever way :o)
> !
> !The 'fields_equiv.php' file is indeed a clever trick to work around the
> !case sensitivity problem, I never thought of that and I never thought
> !that was possible in PHP. I can make my script so that it spit's out all
> !SQL querys with a mixedcase result so while running it on a test server
> !it can detect the situation and allows to analyze if we are going into
> !the right direction and didn't miss a query. When I have some time I'll
> !put this in the code to, and again doing some code clean up..... :-)
> !
> !> Note that FB and its followers don't use quotes when using arrays. I
> mean
> !> that these two statements are different:
> !>
> !> $this_array[Item];
> !> $this_array['Item'];
> !Corect...
> !
> !> In most cases it returns the same item from the array, but there's a
> !> special case when it returns different results.
> !>
> !> define('Item', 'item');
> !>
> !> $this_array[Item];
> !> $this_array['Item'];
> !>
> !> Now we have what we want. ;o)
> !:-D
> !
> !> In a first though, I have imagined that if FB discovers it he could
> make
> !> things harder, but as long as we have a set of scripts/regex to update
> new
> !> versions we can solve this very easy.
> !
> !Are you saying here that FB make it hard for us to do a port????? Or don't
> I
> !understand this correctly???
>
> I expect everything from him, after knowing his ideas about free software
> and free development...
>
> !
> !>
> !> !
> !> !> The main problem with rewriting SQL on the fly is that it might
> bring
> !> !> performance problems. I don't know if you agree with my aproach (do a
> !> !> branch instead plugin or something like).
> !> !>
> !> !I totally agree with your aproach but there are some things:
> !> !
> !> !1) It's differcult for your parser to do the rewriting because some
> !> !fields in the PHP4 code is calculated and so in PHP4 code it really
> does
> !> !not look like a query at all but with some clever scripts we may
> !> !overcome this. Still my rewriter may help you with it.
> !>
> !> Actually I plan to analize exclusively whole parts of the code, I mean,
> !> ignore the dynamic part of the queries.
> !Okey.. and the rest by hand?? I didn't searched thrue the code so I don't
> know
> !the percentage that can by automated or not.. But rewriting PHP code with
> a
> !script just seems dangerous te me...but on the other hand I'm not a realy
> !script/perl/regex wizard to judge....
>
> That's why I think that your method is better then mine. Although I have
> my reasons, your approach is much more generic.
>
> !
> !> !
> !> !2) I agree that it does need extra processor time and the current setup
> !> relays
> !> !heavenly on the backend but in the code we can cache somethings to
> speed
> !> the
> !> !rewriter up a lot. Most of the processor time will be in postgresql
> anyway
> !> and
> !> !I think that PHP4 is verly fast and computers aren't that expensive
> !> anymore..
> !>
> !> I think that PHP-Nuke is a unexpensive option, and that's why it uses
> !> MySQL (lower CPU consumption). I'm trying to port it to PostgreSQL
> because
> !> it is a database highly accepted between corporations due to it
> !> strongness, and due to padronization (that's what corporations want)
> !I think it postgresql is cheap to...so is hardware... But I think he
> php_nuke
> !developers are just MySQL users and love the way MySQL just is so forgiven
> in
> !many ways and is easy to install and administer and ofcourse it's a
> historical
> !thing.
>
> I know this, but we need corporate support so we can grow as popular
> branch/fork.
>
> !
> !>
> !> But we can work on both cases and test wich is better. Or even a
> !> friendly
> !> fork ;o) (I don't like the second option, but it's better if
> !>it's friendly
> !> :o)
> !Sure... Maby WE could make the effort the make the
> !'engine' fast and do a 'native' port to postgresql to speed things up
> !AND provide the rewriters scripts the 'support' 3th party blocks/modules
> !etc. etc. etc. So a not so good developer does not have to bother with
> !diving into code but just want's to have it's site running. We MUST make
> !sure that there isn't a good reason anymore NOT to choose for postgreSQL
> !and we can do this to also support 3th party modules. I don't want
> !people moving to mysql because 3th party module/block X does not work.
>
> Perfect!
>
> I like to listen to other opinions, altough I'll need to throw some code
> away. But a good idea is a good idea and it deserves the credit.
>
> I was contacted today by another voluteer, I'll setup a mailing list
> (pg-nuke-devel) so we can chat and let others know what we are talking
> about, and what we are deciding.
>
> I'll wait your tarball. ;o)
>
> mazza.
>
>
|
|
From: Fabio A M. <ma...@al...> - 2003-05-27 03:38:01
|
-------------------- Looking for a better .sig. Suggestions are being accepted. ---------- Forwarded message ---------- Date: Sun, 25 May 2003 19:13:38 +0200 From: rv...@dd... To: Fabio A Mazzarino <ma...@al...> Subject: pg-Nuke Hey Fabio, how are you these days? Hopefully your headage didn't stayed to long last week. In the mean time I have added a SQL cach to the code so it releases the backend from the SQL calls I make, I also found a little bug in the sql_explode function. Aparently a '' is the escape code for ' in MySQL and I splitted the string on such a double quote. I'm currently not sure what happens with more quotes.... It seems the webpages are generated about twice as fast then without the cache code. I mode it so that it can use shared memory when available but i coulnd't make it to work yet... Ries |
|
From: Fabio A M. <ma...@al...> - 2003-05-27 03:37:10
|
-------------------- Looking for a better .sig. Suggestions are being accepted. ---------- Forwarded message ---------- Date: Mon, 19 May 2003 07:00:10 +0200 From: rv...@dd... To: Fabio A Mazzarino <ma...@al...> Subject: Re: Current status... Hey Fabio, thanks for the reply!! I did test the CVS but it didn't work here and there is a logic resion. PG is casesensitive while MySQL is. For example: SELECT Default_Theme FROM nuke_config; will result dat in MySQL it looks for a field name called 'Default_Theme' while in PG it's all converted to lowercase. This is default SQL behavure.. Also I found that there is a difference between the field type char(12) in MySQL and char(12) in PG. In MySQL it just means a string with a varying length of 12 chars. In PG it means a string of the size 50 chars, filled with spaces to match the 12 length. This will returned in mysql on a select: 'returned' PG will return:'returned ' Also I found some date anomalies Still I rewrite SQL on the fly, and you want to rewrite it before the code is executed. We can use my code to help the perl script to convert the lines in the source.Simply because my code knows about the field types and field names in the DB. Anyway.. My sf account is 'rvt' and I know a bit of CVS. My code is a bit pretier but still needs cleanup and optimalisation. What I wanted is the get started to work with PG fast..so other people will see the effort and start using postgresql to... ries Citeren Fabio A Mazzarino <ma...@al...>: > > rvt: > > I was in the bath just thinking about this. > > I thought a lot last week, and couldn't really code because I had a major > problem with my monitor. Now that I've spent R$ 40,00 to feed him (my > monitor) I can get back to work. > > At CVS there already is a working nuke.sql, so we can start testing it, > it worked fine here with me. > > Let's take a look to your email... > > -------------------- > Looking for a better .sig. Suggestions are being accepted. > > On Sun, 18 May 2003 rv...@dd... wrote: > > ! > ! > !Hey Mazza, > ! > ! > !what's the current status of pg_nuke? I found some time today to work on > the > !rewriter again. Things are working better and better.. > > Oops, I'm kind of out of date. I need to know what this re-writer is > about. Is this some of that set of scripts that I've told you sometime > ago? > > ! > !Attached you find a example of what the rewriter currently does in the > file > !psql.txt > !Also I added my nuke_pg_.sql file. You can do a diff the see the changes > !between yours and mine.. > > psql.txt? I'll take a look and get back to write to you about it. ;o) > > About your nuke_pg_.sql, I think that we must choose the least buggy we > have. Let's take a look. > > ! > !Currently the rewriter is in alpha/beta stage... It does a fairly good job > but > !it's current not very efficient, It talks to the backend to much but this > can > !easely be solved... > > Geez, alpha/beta, that's faster then I :o) Let me take a look. What > language are you using? > > Do you wanna know... I've imagined something like a perl script that > applies regexp's to the whole set of files, so all we have to do each bug > found and each new version is update the set of regexp's. I think that it > is possible because all queries seems very alike, so it probably will > work. > > ! > !If you add me as a maintainer I can insert the code.. Again, currently I > !modified only a few lines in the DB layers so the origional nuke code > !stays the same... > > That's good, but I think that we must be careful with CVS. I've already > been a code master for a time, and sometimes CVS can be tricky, do you > know how to deal with it? > > The true is that you really deserve to be a mantainer, but I need your SF > login to add you there. > > ! > !Will you let me know what you think? I have send you two mails before but > I > !didn't got any resonse > > I want you to know everything is going on, but recently I was unable to > keep you uptodate. > > I promisse I'll keep contact. > > mazza > > |
|
From: Fabio A M. <ma...@al...> - 2003-05-27 03:36:23
|
--------------------
Looking for a better .sig. Suggestions are being accepted.
---------- Forwarded message ----------
Date: Wed, 21 May 2003 09:34:48 +0200
From: rv...@dd...
To: Fabio A Mazzarino <ma...@al...>
Subject: Re: Current status...
Citeren Fabio A Mazzarino <ma...@al...>:
Hey Fabio,
See comments between below.
Here is my site's IP again with my new code, I didn't test all modules but I
didn't fine any anomalys so far, Currently I do a debug level 3 on postgreSQL
to see what and where it goes wrong: http://213.73.163.64:8080
I see I'm a developer now... would you like me to add my code so you can se
what I'm doing and how it works???
regards,
Ries van Twisk
>
> let's see... (hmmm.. interesting... :o)
>
> --------------------
> Looking for a better .sig. Suggestions are being accepted.
>
> On Tue, 20 May 2003 rv...@dd... wrote:
>
> !Fabio,
> !
> !
> !one question about case sensitivity, do your run windows on your
> !apache/php machine or do you have a all *nix situation?? I believe, if I
> !rememeber correctly that PHP4 is NOT case sensitive on a windows
> !platform. I think that postgreSQL on windows runs onder cygwin so the
> !behafure is the same omn *nix or windows. For your information my test
> !machine is a P233/3x4Gb HD/128MB ram/Debian Woody/PHP4/Apache
> !1.3.x/PostgreSQL 7.2.x
>
> Now I remember this feature, I solved this in a very clever way :o)
The 'fields_equiv.php' file is indeed a clever trick to work around the case
sensitivity problem, I never thought of that and I never thought that was
possible in PHP. I can make my script so that it spit's out all SQL querys with
a mixedcase result so while running it on a test server it can detect the
situation and allows to analyze if we are going into the right direction and
didn't miss a query. When I have some time I'll put this in the code to, and
again doing some code clean up..... :-)
> Note that FB and its followers don't use quotes when using arrays. I mean
> that these two statements are different:
>
> $this_array[Item];
> $this_array['Item'];
Corect...
> In most cases it returns the same item from the array, but there's a
> special case when it returns different results.
>
> define('Item', 'item');
>
> $this_array[Item];
> $this_array['Item'];
>
> Now we have what we want. ;o)
:-D
> In a first though, I have imagined that if FB discovers it he could make
> things harder, but as long as we have a set of scripts/regex to update new
> versions we can solve this very easy.
Are you saying here that FB make it hard for us to do a port????? Or don't I
understand this correctly???
>
> !
> !> The main problem with rewriting SQL on the fly is that it might bring
> !> performance problems. I don't know if you agree with my aproach (do a
> !> branch instead plugin or something like).
> !>
> !I totally agree with your aproach but there are some things:
> !
> !1) It's differcult for your parser to do the rewriting because some
> !fields in the PHP4 code is calculated and so in PHP4 code it really does
> !not look like a query at all but with some clever scripts we may
> !overcome this. Still my rewriter may help you with it.
>
> Actually I plan to analize exclusively whole parts of the code, I mean,
> ignore the dynamic part of the queries.
Okey.. and the rest by hand?? I didn't searched thrue the code so I don't know
the percentage that can by automated or not.. But rewriting PHP code with a
script just seems dangerous te me...but on the other hand I'm not a realy
script/perl/regex wizard to judge....
> !
> !2) I agree that it does need extra processor time and the current setup
> relays
> !heavenly on the backend but in the code we can cache somethings to speed
> the
> !rewriter up a lot. Most of the processor time will be in postgresql anyway
> and
> !I think that PHP4 is verly fast and computers aren't that expensive
> anymore..
>
> I think that PHP-Nuke is a unexpensive option, and that's why it uses
> MySQL (lower CPU consumption). I'm trying to port it to PostgreSQL because
> it is a database highly accepted between corporations due to it
> strongness, and due to padronization (that's what corporations want)
I think it postgresql is cheap to...so is hardware... But I think he php_nuke
developers are just MySQL users and love the way MySQL just is so forgiven in
many ways and is easy to install and administer and ofcourse it's a historical
thing.
>
> But we can work on both cases and test wich is better. Or even a friendly
> fork ;o) (I don't like the second option, but it's better if it's friendly
> :o)
Sure... Maby WE could make the effort the make the 'engine' fast and do
a 'native' port to postgresql to speed things up AND provide the rewriters
scripts the 'support' 3th party blocks/modules etc. etc. etc. So a not so good
developer does not have to bother with diving into code but just want's to have
it's site running.
We MUST make sure that there isn't a good reason anymore NOT to choose for
postgreSQL and we can do this to also support 3th party modules. I don't want
people moving to mysql because 3th party module/block X does not work.
>
> !
> !One other thing is that there are many many people who write
> !modules/blocks that aren't part of the nuke tarball. With the my2pg
> !script and the rewriter layer it may help people to convert a
> !module/block themselfse without running a script that converts the PHP4
> !code so new blocks can be added easely without modifing code.
>
> At this point I must agree with you, it's must simplier to create a new
> layer than to rewrite the code. That's why I have propoused a set of
> scripts that should do the convertion.
So above..
>
> This solve the problem pointed bellow.
>
> !
> !and secondly when a new version of nuke comes out..do we have to do it
> !again or do you think your script can just run over the code and convert
> !it succesfully?
>
> Of course that I don't think that it can solve the whole problem, but it
> can make possible to release a new version just few weeks after the new
> release, and possible can bring new developers to our branch, which can
> turn it into a fork.
>
> !
> !Anyway..I tested the CVS but it really didn't work at my site, it just
> !complains about not finding a theme.
>
> To solve this you need to make that define thing, I'm sending the file to
> you (include it into an important include file).
Thanks, I'll test!
>
> !
> !BTW: Where you from? can we setup a IRC session at some time?
>
> I'm from Brazil (GMT -3), and we can setup an IRC session, we only need
> to syncronize our time zones ;o)
>
> !
> !Going to work now....have fun!!!
>
> going to sleep now (0:00). Let's have fun!
>
> mazza.
>
> !
> !Ries
> !
> !Citeren Fabio A Mazzarino <ma...@al...>:
> !
> !>
> !> (see comments bellow)
> !>
> !> --------------------
> !> Looking for a better .sig. Suggestions are being accepted.
> !>
> !> On Mon, 19 May 2003 rv...@dd... wrote:
> !>
> !> !Hey Fabio,
> !> !
> !> !thanks for the reply!!
> !> !
> !> !I did test the CVS but it didn't work here and there is a logic resion.
> PG
> !> is
> !> !casesensitive while MySQL is. For example:
> !> !SELECT Default_Theme FROM nuke_config;
> !> !will result dat in MySQL it looks for a field name called
> 'Default_Theme'
> !> !while in PG it's all converted to lowercase. This is default SQL
> !> behavure..
> !>
> !> I don't understand, here PostgreSQL isn't case sensitive too, but it
> !> worked fine, I'll try a new update. :o/
> !>
> !> !
> !> !Also I found that there is a difference between the field type char(12)
> in
> !> !MySQL and char(12) in PG.
> !> !
> !> !In MySQL it just means a string with a varying length of 12 chars.
> !> !In PG it means a string of the size 50 chars, filled with spaces to
> match
> !> the
> !> !12 length.
> !> !
> !> !This will returned in mysql on a select: 'returned'
> !> !PG will return:'returned '
> !>
> !> Geez, this might become a major problem. We must change all char(n)
> types
> !> to varchar(n), so PostgreSQL will handle data properly.
> !>
> !> !
> !> !Also I found some date anomalies
> !> !
> !> !Still I rewrite SQL on the fly, and you want to rewrite it before the
> code
> !> is
> !> !executed. We can use my code to help the perl script to convert the
> lines
> !> in
> !> !the source.Simply because my code knows about the field types and field
> !> names
> !> !in the DB.
> !>
> !> The main problem with rewriting SQL on the fly is that it might bring
> !> performance problems. I don't know if you agree with my aproach (do a
> !> branch instead plugin or something like).
> !>
> !> !
> !> !Anyway..
> !> !
> !> !My sf account is 'rvt' and I know a bit of CVS.
> !>
> !>
> !> considered added to the project.
> !>
> !> mazza.
> !>
> !> !
> !> !My code is a bit pretier but still needs cleanup and optimalisation.
> What
> !> I
> !> !wanted is the get started to work with PG fast..so other people will
> see
> !> the
> !> !effort and start using postgresql to...
> !> !
> !> !ries
> !> !
> !> !
> !> !
> !> !
> !> !
> !> !
> !> !
> !> !Citeren Fabio A Mazzarino <ma...@al...>:
> !> !
> !> !>
> !> !> rvt:
> !> !>
> !> !> I was in the bath just thinking about this.
> !> !>
> !> !> I thought a lot last week, and couldn't really code because I had a
> !> major
> !> !> problem with my monitor. Now that I've spent R$ 40,00 to feed him (my
> !> !> monitor) I can get back to work.
> !> !>
> !> !> At CVS there already is a working nuke.sql, so we can start testing
> it,
> !> !> it worked fine here with me.
> !> !>
> !> !> Let's take a look to your email...
> !> !>
> !> !> --------------------
> !> !> Looking for a better .sig. Suggestions are being accepted.
> !> !>
> !> !> On Sun, 18 May 2003 rv...@dd... wrote:
> !> !>
> !> !> !
> !> !> !
> !> !> !Hey Mazza,
> !> !> !
> !> !> !
> !> !> !what's the current status of pg_nuke? I found some time today to
> work
> !> on
> !> !> the
> !> !> !rewriter again. Things are working better and better..
> !> !>
> !> !> Oops, I'm kind of out of date. I need to know what this re-writer is
> !> !> about. Is this some of that set of scripts that I've told you
> sometime
> !> !> ago?
> !> !>
> !> !> !
> !> !> !Attached you find a example of what the rewriter currently does in
> the
> !> !> file
> !> !> !psql.txt
> !> !> !Also I added my nuke_pg_.sql file. You can do a diff the see the
> !> changes
> !> !> !between yours and mine..
> !> !>
> !> !> psql.txt? I'll take a look and get back to write to you about it.
> ;o)
> !> !>
> !> !> About your nuke_pg_.sql, I think that we must choose the least buggy
> we
> !> !> have. Let's take a look.
> !> !>
> !> !> !
> !> !> !Currently the rewriter is in alpha/beta stage... It does a fairly
> good
> !> job
> !> !> but
> !> !> !it's current not very efficient, It talks to the backend to much but
> !> this
> !> !> can
> !> !> !easely be solved...
> !> !>
> !> !> Geez, alpha/beta, that's faster then I :o) Let me take a look. What
> !> !> language are you using?
> !> !>
> !> !> Do you wanna know... I've imagined something like a perl script that
> !> !> applies regexp's to the whole set of files, so all we have to do each
> !> bug
> !> !> found and each new version is update the set of regexp's. I think
> that
> !> it
> !> !> is possible because all queries seems very alike, so it probably will
> !> !> work.
> !> !>
> !> !> !
> !> !> !If you add me as a maintainer I can insert the code.. Again,
> currently
> !> I
> !> !> !modified only a few lines in the DB layers so the origional nuke
> code
> !> !> !stays the same...
> !> !>
> !> !> That's good, but I think that we must be careful with CVS. I've
> already
> !> !> been a code master for a time, and sometimes CVS can be tricky, do
> you
> !> !> know how to deal with it?
> !> !>
> !> !> The true is that you really deserve to be a mantainer, but I need
> your
> !> SF
> !> !> login to add you there.
> !> !>
> !> !> !
> !> !> !Will you let me know what you think? I have send you two mails
> before
> !> but
> !> !> I
> !> !> !didn't got any resonse
> !> !>
> !> !> I want you to know everything is going on, but recently I was unable
> to
> !> !> keep you uptodate.
> !> !>
> !> !> I promisse I'll keep contact.
> !> !>
> !> !> mazza
> !> !>
> !> !>
> !> !
> !> !
> !> !
> !>
> !>
> !
> !
> !
>
|
|
From: Fabio A M. <ma...@al...> - 2003-05-27 03:36:00
|
-------------------- Looking for a better .sig. Suggestions are being accepted. ---------- Forwarded message ---------- Date: Tue, 20 May 2003 07:11:55 +0200 From: rv...@dd... To: Fabio A Mazzarino <ma...@al...> Subject: Re: Current status... Fabio, one question about case sensitivity, do your run windows on your apache/php machine or do you have a all *nix situation?? I believe, if I rememeber correctly that PHP4 is NOT case sensitive on a windows platform. I think that postgreSQL on windows runs onder cygwin so the behafure is the same omn *nix or windows. For your information my test machine is a P233/3x4Gb HD/128MB ram/Debian Woody/PHP4/Apache 1.3.x/PostgreSQL 7.2.x > The main problem with rewriting SQL on the fly is that it might bring > performance problems. I don't know if you agree with my aproach (do a > branch instead plugin or something like). > I totally agree with your aproach but there are some things: 1) It's differcult for your parser to do the rewriting because some fields in the PHP4 code is calculated and so in PHP4 code it really does not look like a query at all but with some clever scripts we may overcome this. Still my rewriter may help you with it. 2) I agree that it does need extra processor time and the current setup relays heavenly on the backend but in the code we can cache somethings to speed the rewriter up a lot. Most of the processor time will be in postgresql anyway and I think that PHP4 is verly fast and computers aren't that expensive anymore.. One other thing is that there are many many people who write modules/blocks that aren't part of the nuke tarball. With the my2pg script and the rewriter layer it may help people to convert a module/block themselfse without running a script that converts the PHP4 code so new blocks can be added easely without modifing code. and secondly when a new version of nuke comes out..do we have to do it again or do you think your script can just run over the code and convert it succesfully? Anyway..I tested the CVS but it really didn't work at my site, it just complains about not finding a theme. BTW: Where you from? can we setup a IRC session at some time? Going to work now....have fun!!! Ries Citeren Fabio A Mazzarino <ma...@al...>: > > (see comments bellow) > > -------------------- > Looking for a better .sig. Suggestions are being accepted. > > On Mon, 19 May 2003 rv...@dd... wrote: > > !Hey Fabio, > ! > !thanks for the reply!! > ! > !I did test the CVS but it didn't work here and there is a logic resion. PG > is > !casesensitive while MySQL is. For example: > !SELECT Default_Theme FROM nuke_config; > !will result dat in MySQL it looks for a field name called 'Default_Theme' > !while in PG it's all converted to lowercase. This is default SQL > behavure.. > > I don't understand, here PostgreSQL isn't case sensitive too, but it > worked fine, I'll try a new update. :o/ > > ! > !Also I found that there is a difference between the field type char(12) in > !MySQL and char(12) in PG. > ! > !In MySQL it just means a string with a varying length of 12 chars. > !In PG it means a string of the size 50 chars, filled with spaces to match > the > !12 length. > ! > !This will returned in mysql on a select: 'returned' > !PG will return:'returned ' > > Geez, this might become a major problem. We must change all char(n) types > to varchar(n), so PostgreSQL will handle data properly. > > ! > !Also I found some date anomalies > ! > !Still I rewrite SQL on the fly, and you want to rewrite it before the code > is > !executed. We can use my code to help the perl script to convert the lines > in > !the source.Simply because my code knows about the field types and field > names > !in the DB. > > The main problem with rewriting SQL on the fly is that it might bring > performance problems. I don't know if you agree with my aproach (do a > branch instead plugin or something like). > > ! > !Anyway.. > ! > !My sf account is 'rvt' and I know a bit of CVS. > > > considered added to the project. > > mazza. > > ! > !My code is a bit pretier but still needs cleanup and optimalisation. What > I > !wanted is the get started to work with PG fast..so other people will see > the > !effort and start using postgresql to... > ! > !ries > ! > ! > ! > ! > ! > ! > ! > !Citeren Fabio A Mazzarino <ma...@al...>: > ! > !> > !> rvt: > !> > !> I was in the bath just thinking about this. > !> > !> I thought a lot last week, and couldn't really code because I had a > major > !> problem with my monitor. Now that I've spent R$ 40,00 to feed him (my > !> monitor) I can get back to work. > !> > !> At CVS there already is a working nuke.sql, so we can start testing it, > !> it worked fine here with me. > !> > !> Let's take a look to your email... > !> > !> -------------------- > !> Looking for a better .sig. Suggestions are being accepted. > !> > !> On Sun, 18 May 2003 rv...@dd... wrote: > !> > !> ! > !> ! > !> !Hey Mazza, > !> ! > !> ! > !> !what's the current status of pg_nuke? I found some time today to work > on > !> the > !> !rewriter again. Things are working better and better.. > !> > !> Oops, I'm kind of out of date. I need to know what this re-writer is > !> about. Is this some of that set of scripts that I've told you sometime > !> ago? > !> > !> ! > !> !Attached you find a example of what the rewriter currently does in the > !> file > !> !psql.txt > !> !Also I added my nuke_pg_.sql file. You can do a diff the see the > changes > !> !between yours and mine.. > !> > !> psql.txt? I'll take a look and get back to write to you about it. ;o) > !> > !> About your nuke_pg_.sql, I think that we must choose the least buggy we > !> have. Let's take a look. > !> > !> ! > !> !Currently the rewriter is in alpha/beta stage... It does a fairly good > job > !> but > !> !it's current not very efficient, It talks to the backend to much but > this > !> can > !> !easely be solved... > !> > !> Geez, alpha/beta, that's faster then I :o) Let me take a look. What > !> language are you using? > !> > !> Do you wanna know... I've imagined something like a perl script that > !> applies regexp's to the whole set of files, so all we have to do each > bug > !> found and each new version is update the set of regexp's. I think that > it > !> is possible because all queries seems very alike, so it probably will > !> work. > !> > !> ! > !> !If you add me as a maintainer I can insert the code.. Again, currently > I > !> !modified only a few lines in the DB layers so the origional nuke code > !> !stays the same... > !> > !> That's good, but I think that we must be careful with CVS. I've already > !> been a code master for a time, and sometimes CVS can be tricky, do you > !> know how to deal with it? > !> > !> The true is that you really deserve to be a mantainer, but I need your > SF > !> login to add you there. > !> > !> ! > !> !Will you let me know what you think? I have send you two mails before > but > !> I > !> !didn't got any resonse > !> > !> I want you to know everything is going on, but recently I was unable to > !> keep you uptodate. > !> > !> I promisse I'll keep contact. > !> > !> mazza > !> > !> > ! > ! > ! > > |
|
From: Fabio A M. <ma...@al...> - 2003-05-27 03:35:59
|
-------------------- Looking for a better .sig. Suggestions are being accepted. ---------- Forwarded message ---------- Date: Sun, 18 May 2003 17:33:47 -0300 (BRT) From: Fabio A Mazzarino <ma...@al...> To: rv...@dd... Cc: ma...@us... Subject: Re: Current status... rvt: I was in the bath just thinking about this. I thought a lot last week, and couldn't really code because I had a major problem with my monitor. Now that I've spent R$ 40,00 to feed him (my monitor) I can get back to work. At CVS there already is a working nuke.sql, so we can start testing it, it worked fine here with me. Let's take a look to your email... -------------------- Looking for a better .sig. Suggestions are being accepted. On Sun, 18 May 2003 rv...@dd... wrote: ! ! !Hey Mazza, ! ! !what's the current status of pg_nuke? I found some time today to work on the !rewriter again. Things are working better and better.. Oops, I'm kind of out of date. I need to know what this re-writer is about. Is this some of that set of scripts that I've told you sometime ago? ! !Attached you find a example of what the rewriter currently does in the file !psql.txt !Also I added my nuke_pg_.sql file. You can do a diff the see the changes !between yours and mine.. psql.txt? I'll take a look and get back to write to you about it. ;o) About your nuke_pg_.sql, I think that we must choose the least buggy we have. Let's take a look. ! !Currently the rewriter is in alpha/beta stage... It does a fairly good job but !it's current not very efficient, It talks to the backend to much but this can !easely be solved... Geez, alpha/beta, that's faster then I :o) Let me take a look. What language are you using? Do you wanna know... I've imagined something like a perl script that applies regexp's to the whole set of files, so all we have to do each bug found and each new version is update the set of regexp's. I think that it is possible because all queries seems very alike, so it probably will work. ! !If you add me as a maintainer I can insert the code.. Again, currently I !modified only a few lines in the DB layers so the origional nuke code !stays the same... That's good, but I think that we must be careful with CVS. I've already been a code master for a time, and sometimes CVS can be tricky, do you know how to deal with it? The true is that you really deserve to be a mantainer, but I need your SF login to add you there. ! !Will you let me know what you think? I have send you two mails before but I !didn't got any resonse I want you to know everything is going on, but recently I was unable to keep you uptodate. I promisse I'll keep contact. mazza |
|
From: Fabio A M. <ma...@al...> - 2003-05-27 03:35:48
|
-------------------- Looking for a better .sig. Suggestions are being accepted. ---------- Forwarded message ---------- Date: Sun, 18 May 2003 17:06:50 +0200 From: rv...@dd... To: ma...@us... Subject: Current status... Hey Mazza, what's the current status of pg_nuke? I found some time today to work on the rewriter again. Things are working better and better.. Attached you find a example of what the rewriter currently does in the file psql.txt Also I added my nuke_pg_.sql file. You can do a diff the see the changes between yours and mine.. Currently the rewriter is in alpha/beta stage... It does a fairly good job but it's current not very efficient, It talks to the backend to much but this can easely be solved... If you add me as a maintainer I can insert the code.. Again, currently I modified only a few lines in the DB layers so the origional nuke code stays the same... Will you let me know what you think? I have send you two mails before but I didn't got any resonse best regards, Ries van Twisk |
|
From: Fabio A M. <ma...@al...> - 2003-05-27 03:34:41
|
-------------------- Looking for a better .sig. Suggestions are being accepted. ---------- Forwarded message ---------- Date: Mon, 12 May 2003 09:31:57 +0200 From: rv...@dd... To: ma...@al... Subject: Codecleanup.... Hai Mazza, I did some code cleanup on my code and added some rewrite rules to it... Currently I only need to add a few lines of code in the following files: - sql_layer.hp - postgres7.php this website (http://213.73.163.64:8080) does handle case sensitivity DB handly but after some thinking about it I will convert anything to lowercase (like you did) and handle cansensitive at a other place any my layer. for example: 'SELECT MyID FROM nuke_ids;' will be interpetated as : 'SELECT myid FROM nukes_ids; by postgresql;' If in the PHP code the programmer uses something like this: '$userid = $Result [MyID];' Then the string will always be empty. Because the value =s found at '$Result[myid];' What I'm going to do is rewrite it like this: 'SELECT myid AS "MyID" FROM nukes_ids;' So PHP will store the correct result in right place in the array.. That will be last thing I will do before I send you the code. Here is the URL: of the site running the rewriter: http://213.73.163.64:8080 regards, Ries van Twisk Citeren ma...@al...: > > rvt: > > I already have a nuke.sql version for PostgreSQL. If you are interested you > can find it at the CVS repository at sourceforge.net/projects/pg-nuke, inside > pg-nuke tree. > > As you can see I am really porting PHP-Nuke to PostgreSQL, FB hasn't aswered > my emails so I porting by myself. I'd like to invite you to participate as a > developer. > > I have already changed nuke.sql and located all INSERT NULL problems. > > Hope you get interested. > > mazza > > |
|
From: Fabio A M. <ma...@al...> - 2003-05-27 03:34:13
|
-------------------- Looking for a better .sig. Suggestions are being accepted. ---------- Forwarded message ---------- Date: Sun, 11 May 2003 07:34:50 +0200 From: rv...@dd... To: ma...@al... Subject: Re: About PHP-Nuke for PostgreSQL What I will do is do some code cleanup and and send you a diff. so you can see what it looks like.. Ries rvt: Sorry if you have already received a reply of your email, but I'm having some problems with my internet connection. Se comments above... -------------------- Looking for a better .sig. Suggestions are being accepted. On Tue, 6 May 2003 rv...@dd... wrote: !Hai Mazza, ! !thank you for your response. ! !I didn't do any work on a postgresql port anymore (it's a home project now...) !because I didn't got any responces from any of the nuke developers.. :( !I'll do a checkout asap and check it.. IMO there's no serious developer team, I think that the only one who can actually code is FB. That's because of the way he treats volunteers. I still can't believe that he wants to charge $10 to recevei help from volunteers :oP ! !Appart from the null insert I also found some other 'strange' effects on the !SQL part.... I'll check when I'm at home.. ! Try to list these kind of problems it'll be very helpful. I have been contacted by a tested intereste in testing PG-Nuke, I hope he'll be very helpfull to. ! !What about a next version??? Do you have to do it all over again??? ! Well, at the beggining I do not pretend to become a PHP-Nuke fork, but nothing more then a branch, if it becomes necessary in the future we might become a fork, but only maturity will show us the way. !What I tryed to do create a SQL rewriter that sits somehwere in the DB layer.. I though in a solution like this before, but it would probably takes too much time and would make impossible to keep a branch, I mean, it would take too long to convert everything again. I have an better idea. ! !To initialize the database I use a tool to convert a MSQL export to a !postgresql export which seems to do the job really well (only one change !in the final output). I have used one to my2pg, it's a very inteligent Perl script, very few adjusts were needed. ! !What do you do with all the modules create by 3d party developers?? That's where my idea fits better. I'm planing to develop a small set of scripts, probably using Perl and/or sed, to automaticly convert special queries, exactly those which aren't compatible. So the first script would convert the NULL insertion that we are having problem, the other would convert the limit problem, and so on. I think that it would be the better thing to do, we could generate very fast converted versions, including 3rd part ones. What do you think? mazza. ! !I'll keep in contact... !Ries van Twisk ! !Citeren ma...@al...: ! !> !> rvt: !> !> I already have a nuke.sql version for PostgreSQL. If you are interested you !> can find it at the CVS repository at sourceforge.net/projects/pg-nuke, inside !> pg-nuke tree. !> !> As you can see I am really porting PHP-Nuke to PostgreSQL, FB hasn't aswered !> my emails so I porting by myself. I'd like to invite you to participate as a !> developer. !> !> I have already changed nuke.sql and located all INSERT NULL problems. !> !> Hope you get interested. !> !> mazza !> !> ! ! |
