php-general Digest 18 Feb 2013 11:19:25 -0000 Issue 8127
Topics (messages 320231 through 320235):
Re: OOP to run sequential SQL queries?
320231 by: Marco Behnke
320232 by: Serge Fonville
320233 by: tamouse mailing lists
Re: webDAV/CalDAV client class experience ?
320234 by: tamouse mailing lists
320235 by: B. Aerts
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
Am 17.02.13 17:00, schrieb AmirBehzad Eslami:
> Dear list,
>
> We have a bunch of SQL-queries, they should be executed in
> a sequential order, with a defensive programming style in mind.
I don't understand what you want?
Queries are executed sequentially or do you plan to create a
multi-process PHP application?
>
> We were thinking to implement the solution as "Stored Procedures"
> instead of a PHP solution that runs SQL queries, but an article in
> Coding Horro recommendeds to avoid SP for good reasons:
>
> http://www.codinghorror.com/blog/2004/10/who-needs-stored-procedures-anyways.html
>
> Now we're going to carry on in PHP, and my experience says that
> we should write the solution in a procedural-style, instead of OOP.
>
> Is there any benefit to use OOP in these situations?
>
> Please share your thoughts.
>
> Thanks,
> -behzad
>
--
Marco Behnke
Dipl. Informatiker (FH), SAE Audio Engineer Diploma
Zend Certified Engineer PHP 5.3
Tel.: 0174 / 9722336
e-Mail: ma...@behnke.biz
Softwaretechnik Behnke
Heinrich-Heine-Str. 7D
21218 Seevetal
http://www.behnke.biz
signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
Hi,
We were thinking to implement the solution as "Stored Procedures"
> instead of a PHP solution that runs SQL queries, but an article in
> Coding Horro recommendeds to avoid SP for good reasons:
The article shows only one thing. that common practice should be to 'do
everything where it belongs'
If you implement this practice within your application, it becomes more
maintainable, more performant and easier to develop.
Also, to determine the styles used to write your code, is almost entirely
dependent on a few things:
* Programmer's preference
* The problem you are solving
* The standards that are commonly used in the environment you are in
Is there any benefit to use OOP in these situations?
Benefits of OOP are that it becomes easier to implement a more standardized
code structure, better match with reality, clearer code, more structure,
re-usability, and a modular design.
These can all be done in procedural code as well, the difference being you
need a different mind- and skillset.
HTH
Kind regards/met vriendelijke groet,
Serge Fonville
http://www.sergefonville.nl
Convince Microsoft!
They need to add TRUNCATE PARTITION in SQL Server
https://connect.microsoft.com/SQLServer/feedback/details/417926/truncate-partition-of-partitioned-table
2013/2/17 Marco Behnke <ma...@behnke.biz>
> Am 17.02.13 17:00, schrieb AmirBehzad Eslami:
> > Dear list,
> >
> > We have a bunch of SQL-queries, they should be executed in
> > a sequential order, with a defensive programming style in mind.
> I don't understand what you want?
> Queries are executed sequentially or do you plan to create a
> multi-process PHP application?
> >
> > We were thinking to implement the solution as "Stored Procedures"
> > instead of a PHP solution that runs SQL queries, but an article in
> > Coding Horro recommendeds to avoid SP for good reasons:
> >
> >
> http://www.codinghorror.com/blog/2004/10/who-needs-stored-procedures-anyways.html
> >
> > Now we're going to carry on in PHP, and my experience says that
> > we should write the solution in a procedural-style, instead of OOP.
> >
> > Is there any benefit to use OOP in these situations?
> >
> > Please share your thoughts.
> >
> > Thanks,
> > -behzad
> >
>
>
> --
> Marco Behnke
> Dipl. Informatiker (FH), SAE Audio Engineer Diploma
> Zend Certified Engineer PHP 5.3
>
> Tel.: 0174 / 9722336
> e-Mail: ma...@behnke.biz
>
> Softwaretechnik Behnke
> Heinrich-Heine-Str. 7D
> 21218 Seevetal
>
> http://www.behnke.biz
>
>
>
--- End Message ---
--- Begin Message ---
On Sun, Feb 17, 2013 at 10:00 AM, AmirBehzad Eslami
<behzad.esl...@gmail.com> wrote:
> We have a bunch of SQL-queries, they should be executed in
> a sequential order, with a defensive programming style in mind.
>
> We were thinking to implement the solution as "Stored Procedures"
> instead of a PHP solution that runs SQL queries, but an article in
> Coding Horro recommendeds to avoid SP for good reasons:
>
> http://www.codinghorror.com/blog/2004/10/who-needs-stored-procedures-anyways.html
As has been said, everything has it's place, every tool has it's use,
but we've all used that screwdriver to both open a can of paint and
then bang on the lid with handle to get it closed again. Meaning that
just because there's a tool to hand, it doesn't always mean it's the
right thing.
I tend to use stored procs when what I need to get accomplished
resides well within the database and utilizes the database engine more
effectively, and when such activities might become I/O bandwidth
issues if it were all done serially within the application. In other
words, very few and far between.
If the dataset is large and involves some very complex queries (lots
of nested selects and so on), it is often better as a stored proc. But
there is a caveat there as well in that often times the skill sets for
maintaining complex SQL code can be a lot harder to find and acquire
than the skill set for maintaining the same logic in PHP.
So, no absolutes, one way or another.
> Now we're going to carry on in PHP, and my experience says that
> we should write the solution in a procedural-style, instead of OOP.
>
> Is there any benefit to use OOP in these situations?
>
> Please share your thoughts.
This is actually a very similar question: again, no absolutes. An OO
approach is well fit for some aspects of implementation, and a
procedural approach to others, and then there is the functional
approach, which is yet another way of looking at the problem. Even
with that, all three can come into play in any given application. What
is to be gained by using an object approach, versus procedural, versus
functional? If it's a fairly confined operation, perhaps wrapping it
in an object might give some more portability, and if the rest of the
application utilizes an object approach, would be a good way to go.
If the rest of the application is primarily procedural, then
introducing an object approach might become more of a maintenance
issue.
So, really, it's not a simple answer. There are far too many considerations.
Other things to consider: does the entire series of queries need to be
performed in a locked state, i.e., if the database records change
during the series of queries, will things break? This has very huge
performance considerations, and should be taken into account. One of
the purported uses of stored procs is that it's easier to implement an
atomic operation such as that, but that's really not entirely accurate
either. It's quite possible to lock and release while still running
the queries sequentially from code. The round-trip factors of I/O do
weigh more heavily here.
My overall suggestion: Do it the simplest way you can right now,
measure, charaacterize, look at how the whole app operates, and
refactor what needs to be refactored when you have some actual
performance data.
Recognize also that "simplest" is pretty subjective based upon you and
your fellow devs experiences and points of view. A super DBA person
might be able to snap off a stored proc in no time; while an
experience PHPer might be able to do the same procedurally. It doesn't
mean either one is better than the other. Only putting it into play
and actually measuring it will do that.
Stumbling over how best to do something is very often less optimal
than just implementing and seeing for yourself.
--- End Message ---
--- Begin Message ---
On Sat, Feb 16, 2013 at 2:30 PM, B. Aerts <ba_ae...@yahoo.com> wrote:
> - the biggest mistake: apparently I commented the fwrite() call to the
> stream, which explains why he went in time-out ... (in this case, please DO
> shoot the pianist)
Nah, just don't leave a tip. :)
> - Adding the HTTP header "Accept: */*" made sure all read actions ( e.g.
> GET, PROPFIND, REPORT) worked perfectly
This is interesting. The Accept header has to do with what media types
the browser will accept in return. I didn't think it had anything to
do with what operations the server/application accepts. Must go read
further....
> Only problem remaining was that PUT still isn't possible - at least not with
> one of the providers. Since I used a verbatim copy of a PUT action from the
> RFC, I strongly suspect the problem to be with the provider.
You've no doubt considered this already, but it might be intentional
on the provider's part. I'm not up on all the webDAV/calDAV providers;
I imagine some of them might add in additional layers of auth
(including the NOWAI layer) just to consider themselves more secure.
--- End Message ---
--- Begin Message ---
- Adding the HTTP header "Accept: */*" made sure all read actions ( e.g.
GET, PROPFIND, REPORT) worked perfectly
This is interesting. The Accept header has to do with what media types
the browser will accept in return. I didn't think it had anything to
do with what operations the server/application accepts. Must go read
further....
I'll have to revoke this statement, as I can't reproduce it anymore.
I noticed the DaviCal didn't use it, bu the CURL call did - and yielded
more ( = meaningfull) results.
But, as I said, can't reproduce it.
The thing I could reproduce was that, if the request was sent to the
default port, AND this port was included in the "Host" header, both GET
and PUT yielded HTTP 404.
Only problem remaining was that PUT still isn't possible - at least not with
one of the providers. Since I used a verbatim copy of a PUT action from the
RFC, I strongly suspect the problem to be with the provider.
You've no doubt considered this already, but it might be intentional
on the provider's part. I'm not up on all the webDAV/calDAV providers;
I imagine some of them might add in additional layers of auth
(including the NOWAI layer) just to consider themselves more secure.
Yes I did, but the following arguments should negate that consideration:
- when running OPTIONS, PUT is included in the allowed HTTP methods
- the HTTP return code from the PUT command is 301, where a security
issue would have yielded a code in the 400 range
- I think the CalDAV spec does mention Basic auhentication, so it can't
be anything more sophisticated
- the other provider does respond as expected (though I agree, that is
the weakest argument: expectations != specifications )
- the provider does allow sync'ing Sunbird, iCal, ... over CalDAV, and
that works, even entering a new event (which is a PUT action). The
Charles debugging proxy too shows that it's only Basic authentication
that's going up - and succeeding
I'll add the code I used for the tests.
When looking for the configuration ( Calendar URL, ...), the search term
"CalDAV <provider> Calendar Sunbird" always did the trick for me.
( I also had to modify the Davical client class a bit - make some
protected members public for this test code to work)
if (1)
{
$url =
"https://caldav.calendar.<provider1>.com/dav/ba_aerts/Calendar/tstCalDAV/"
; // make sure it ends in a '/' !
$user = "<usrname1>@<provider1>.com" ;
$pwd = "*********1" ;
}
else
{
$url =
"https://www.<provider2>.com/calendar/dav/<usrname2>@<provider2>.com/events/"
;
$user = "<usrname2>@<provider2>.com" ;
$pwd = "**********2" ;
}
/************************************
* run OPTIONS test *
************************************/
$method = "OPTIONS" ;
$requestHeaders = Array("content-type" => "text/xml",
"Depth" => 1) ;
echo "<UL>\n" ;
echo "<LI>$method request:\n" ;
doCurlRequest($method, $url, $user, $pwd, "", $requestHeaders) ;
doCalDAVClientRequest($method, $url, $user, $pwd, "", $requestHeaders ) ;
echo "</LI> \n" ;
echo
"\r\n<LI>=========================================================================</LI>
\n" ;
/************************************
* run PROPFIND test *
************************************/
$method = "PROPFIND" ;
$body = <<<XML
<D:propfind xmlns:D="DAV:" xmlns:CS="http://calendarserver.org/ns/";
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:prop>
<D:resourcetype />
<D:owner />
<D:current-user-principal />
<D:supported-report-set />
<C:supported-calendar-component-set />
<CS:getctag />
</D:prop>
</D:propfind>
XML;
echo "<LI>$method request:\n" ;
doCurlRequest($method, $url, $user, $pwd, $body, $requestHeaders) ;
doCalDAVClientRequest($method, $url, $user, $pwd, $body, $requestHeaders ) ;
echo "</LI> \n" ;
echo
"\r\n<LI>=========================================================================</LI>
\n" ;
/************************************
* run REPORT test *
************************************/
$method = "REPORT" ;
$body = <<<XML
<?xml version="1.0" encoding="utf-8" ?>
<C:calendar-query xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:prop>
<C:calendar-data/>
<D:getetag/>
</D:prop>
<C:filter>
<C:comp-filter name="VCALENDAR">
<C:comp-filter name="VEVENT">
<C:time-range start="20130201T000001Z" end="20130228T000001Z"/>
</C:comp-filter>
</C:comp-filter>
</C:filter>
</C:calendar-query>
XML;
echo "<LI>$method request:\n" ;
doCurlRequest($method, $url, $user, $pwd, $body, $requestHeaders) ;
doCalDAVClientRequest($method, $url, $user, $pwd, $body, $requestHeaders ) ;
echo "</LI> \n" ;
echo
"\r\n<LI>=========================================================================</LI>
\n" ;
/************************************
* run GET test *
************************************/
$method = "GET" ;
$icsFile = "e26443db-02d4-4bf0-a97c-c1ddbd3126df.ics" ;
echo "<LI>$method request:\n" ;
// some cheating required: check the *.ICS name of an existing
// resource in a previous REPORT run
doCurlRequest($method, $url . $icsFile, $user, $pwd, "", $requestHeaders) ;
doCalDAVClientRequest($method, $url . $icsFile, $user, $pwd, "",
$requestHeaders) ;
echo "</LI> \n" ;
echo
"\r\n<LI>=========================================================================</LI>
\n" ;
/************************************
* run PUT test *
************************************/
$method = "PUT" ;
$UID = "ABCDE" . time() ;
$url .= $UID . ".ICS" ;
$body = <<<ICAL
BEGIN:VCALENDAR
VERSION:2.0
PRODID:PHP heredoc
BEGIN:VEVENT
UID:$UID
SUMMARY:ingevoegd met PUT
DTSTAMP:20130215T123040
DTSTART:20130216T090000
DTEND:20130216T100000
END:VEVENT
END:VCALENDAR
ICAL;
echo "<LI>$method request:\n" ;
$requestHeaders = Array("If-none-match" => "*",
"Accept" => "*/*",
"content-type" => "text/calendar") ;
doCurlRequest($method, $url, $user, $pwd, $body, $requestHeaders) ;
doCalDAVClientRequest($method, $url, $user, $pwd, $body, $requestHeaders ) ;
echo "</LI> \n" ;
echo
"\r\n<LI>=========================================================================</LI>
\n" ;
echo "</UL> \n" ;
die ("End of test") ;
--- End Message ---
