Alan Knowles [2004-07-04 02:19 UTC] There's alot of code to be tidied up before it gets to CS standards,
(XMLParser.php? replace with XML_Parser?).. etc.
Class/Package naming needs to be worked out DB_SqliteTools?
Looks usefull otherwise
David Costa [2004-07-04 02:37 UTC] Hello Alan,
thanks for your kind comments:
"There's alot of code to be tidied up before it gets to CS standards,
(XMLParser.php? replace with XML_Parser?).. etc."
Done for XML_Parser renaming, cleaned up a bit the code for that class too as per CS. (XML_Parser need the comments too I know..will be done asap)
"
Class/Package naming needs to be worked out DB_SqliteTools?"
Sounds like Sqlite_Tools under Databases would make sense but I am open to suggestions.
"Looks usefull otherwise"
Thanks again for your time. Glad to see that it might be useful.
Regards
David Costa
Hans Lellelid [2004-07-04 04:49 UTC] Awesome class, David. I do a lot of work w/ SQLite, so I'll definitely use it.
One thing that I found myself doing was referring often to the class constants to see what the message for thrown Exceptions was. (admittedly it's obvious in many/most cases by looking at context what the throw is.) I noticed also that some constants seem only to be used in one place. I know the PEAR "way" is to use constants for error messages, but I wonder if it might not be clearer to just put the plaintext in your class. (Might also improve performance marginally not to have so many defines.)
The main reason I'd see for using constants is so that the calling code can check the exception for explicity problems. If that's the intent, maybe use the constants for error codes? Generally I've found that it doesn't matter too much, as the messages are almost always for tracking problems rather than programmatic handling.
Anyway, just an observation & a half-suggestion, certainly not a "condition" :) The class looks great.
Stephan Schmidt [2004-07-04 08:21 UTC] Nice packackge, is there a way to get a PHP4 compatible version of this? sqlite also works with PHP4...
And why don't you use a real XML parser instead of the regular expression parser?
Stephan
Stephan Schmidt [2004-07-04 08:27 UTC] Hi,
I hardly recommend using XML_Parser or something similar for creating a database from a dump. sqlite supports databases up to 2 terabytes and this line will certainly reach the memory limit:
$xmlText = file_get_contents( $xmlFile );
As your XML file will be a lot larger that the database...
Using XML_Parser (or the xmlreader extension, if you stick to PHP5) will avoid this problem.
Stephan
Yavor Shahpasov [2004-07-05 02:01 UTC] Renaming a table would be mighty usefull addition
David Costa [2004-07-10 23:01 UTC] Hans wrote : "I know the PEAR "way" is to use constants for error messages, but I wonder if it might not be clearer to just put the plaintext in your class. (Might also improve performance marginally not to have so many defines.)"
Hello Hans,
thanks for taking your time to commend my proposal. As suggested I did removed 5 of the constants that where used only once or could be replaced with an existing one.
I agree it might make it clearer to have all the error messages near the relevant piece of code but I do prefer to keep the text messages all in one place ;)
As you can imagine the users shouldn't have to spent to much to figure out which is what as the Pear_Exception system provides a pretty substantial trackback feedback and hopefully he would have no reason to change the errors output;)
Regards
David
David Costa [2004-07-10 23:12 UTC] Stephan Schmidt Wrote [2004-07-04, 04:27 EDT]
"
I hardly recommend using XML_Parser or something similar for creating a database from a dump. sqlite supports databases up to 2 terabytes and this line will certainly reach the memory limit...
As your XML file will be a lot larger that the database...
Using XML_Parser (or the xmlreader extension, if you stick to PHP5) will avoid this problem"
Hi Stephan,
the realistic database size limit is 2GB unless you are on a 64 bit architecture and you have a really a well customized system.
I am pretty sure that even in a 1 GB database we might have a memory issues ;)
For the time being the XML dump code is highly experimental and surely there are some possible implications with a huge database.
I tried the xmlreader extension but couldn't get it to do the job in my specific case, this might be justified by the fact that I am not an XML guru ;)
If you think that the XML to DB function might really be a sub standard(albeit seems to behave find in realistic database sizes) I could remove that function AND the XML_Parser so in this way the only possibility will be DB to XML and not the other way around.
Another alternative would be an alpha release, some more extensive tests and a more robust solution if needed.
Let me know if you do have any suggestion, by all means my XML knowledge is not comparable to your expertise.
Cheers
David Costa
|
