SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 42 of 42
  1. #26
    Employed Again Viflux's Avatar
    Join Date
    May 2003
    Location
    London, On.
    Posts
    1,127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes, I see that now.

    And thanks for completely owning me on my PHP knowledge lastcraft.

  2. #27
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Viflux
    And thanks for completely owning me on my PHP knowledge lastcraft.
    Sorry, apologies, that was a bit brutal . Just finished work and fighting too much lagacy code of late .

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  3. #28
    SitePoint Zealot johno's Avatar
    Join Date
    Sep 2003
    Location
    Bratislava, Slovakia
    Posts
    184
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    I posted a big list of all the ways I could think of for handling this situation, but I've lost it. The list was missing dependency injection at the end, but I don't think DI is what you need here. Anyway, I cannot find the post now and Sitepoint only allows one search every ten seconds or so.
    I think I've found it. http://www.sitepoint.com/forums/show...43&postcount=7
    Annotations support for PHP5
    TC/OPT™ Group Leader

  4. #29
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Actually that wasn't the one I was thinking of...

    http://www.sitepoint.com/forums/showthread.php?t=249607

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  5. #30
    gimme the uuuuuuuuuuu duuudie's Avatar
    Join Date
    Feb 2004
    Location
    Switzerland
    Posts
    2,253
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    hi guys, I must say that this is a very interesting discussion. really. i got the expected answer (don't use globals, they are evil ) and a few solutions to work around this problem.

    thanks a lot for the link Marcus, it really answers most of my questions.

    just one last thing about the Singleton (as in the above example (c.f beginning of the thread)). Should the bit of code shown above be used in the constructor of classes dealing with a db or in each method?

  6. #31
    SitePoint Enthusiast
    Join Date
    Jun 2004
    Location
    nyc
    Posts
    63
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    A web server has many, many simultaneous requests. Please, please don't tell me you build database driven web sites without using transactions.

    If the connection is global, who begins the transaction? Who commits it? These are synchonisation issues. Issues that you drive a horse and cart through by using a global.
    I read this thread with much interest, and particularly enjoyed this post by Marcus. However I've been thinking about the above quote quite a lot, and it has me both confused and a little concerned about my understanding of how database connections work in PHP.

    Since PHP (unlike say Java) can't use true singleton objects that are accessible in multiple simultaneous processes/requests, wouldn't the simultaneous requests mentioned above actually be handled by different database connection objects? If so, how is there a risk that a transaction would get garbled?

    This also got me thinking about persistent connections, which I've always used as a matter of course. I would think that any risk posed by the above scenario would be ten times as dangerous with the use of persistent connections, since there's a pool of open connections that any script/request/process can use. Again, my understanding was that this was handled automatically, and that the same connection couldn't be used by more than one client at the same time. Am I mistaken in this point as well?

    Sorry if this is all a bit noobish for this forum, but I wanted to post in the context of this discussion since it seems relevant.

    Thanks for any enlightenment you can provide.

  7. #32
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    A web server has many, many simultaneous requests. Please, please don't tell me you build database driven web sites without using transactions.
    If the data is critical and/or the potential for collisions high then transactions are necessary. But the majority of websites database accesses are reads and if writes are light, such as adding a occasional record to a mailing list or adminstrative updates, then most sites can go forever and never get a write error using modern databases.
    If the connection is global, who begins the transaction? Who commits it? These are synchonisation issues. Issues that you drive a horse and cart through by using a global.
    With PHP a single request/response cycle is everything. When the script ends and the connection is closed then the commit would occur. There is no such thing as a transaction running across two requests. You are thinking of long running apps such as desktop applications or application servers.
    Christopher

  8. #33
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I wonder why there seems to be an insistance on singleton patterns (particularly in PHP4) for cases where a static class is much easier to implement, conceptualize and use. Why instance the object when its class code is all you really want? I have a (static) connection class that holds a static array of connection resources. There is no need to wrap each resource in an object -- that is wasteful. As all classes are in the global namespace, there is no issue with accessing it from anywhere and at anytime. It is uniform, it is fast and it is always available. When I switched my codebase to PHP5, I merely re-implemented the function/static var as a real class static var (even though it continued to work as is).

    OOP patterns are both useful and fashionable, to be sure. That doesn't change the fact that procedural patterns are also useful even if they are not as fashionable at the moment. Use the simplest solution possible (but no simpler). Always.

    Best,

  9. #34
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    OOP is rather more than just a fashion, I think.

  10. #35
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    OOP is rather more than just a fashion, I think.
    Surely that is true -- and it is also what I said. Never-the-less, it is only one technique from a myriad of possible techniques. Use the one that is most appropriate for your problem and your toolchain. Sometimes an OOP pattern is the best, sometimes not. That's all I meant to imply.

    Regards,

  11. #36
    SitePoint Addict
    Join Date
    Jan 2005
    Location
    United Kingdom
    Posts
    208
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Out of interest, why do you need to instanciate the database object at all? This might be bad practise but PHP falls back to the last opened database connection regardless of any issue of scope. Furthermore everything else in a database specific abstraction should be fairly static? I appreciate that multi-database setups would have a scope issue.

  12. #37
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    OOP patterns are both useful and fashionable, to be sure. That doesn't change the fact that procedural patterns are also useful even if they are not as fashionable at the moment. Use the simplest solution possible (but no simpler).
    Please don't confuse object-oriented programming with software design-patterns. They may have spawned from the same place, but they deal with different abstration-levels. Most design-patterns can be implemented in whatever you want, though admittedly a few are pretty much tied in to object-oriented languages. (Such as the Singleton)


    Quote Originally Posted by jayboots
    I wonder why there seems to be an insistance on singleton patterns (particularly in PHP4) for cases where a static class is much easier to implement (...)
    Singleton has advantages over a static class. For one thing it can have properties, so it may hold state (A connection-id for example).

  13. #38
    SitePoint Zealot
    Join Date
    Feb 2003
    Posts
    156
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by hennagaijin
    Since PHP (unlike say Java) can't use true singleton objects that are accessible in multiple simultaneous processes/requests, wouldn't the simultaneous requests mentioned above actually be handled by different database connection objects? If so, how is there a risk that a transaction would get garbled?
    A lot of the problems with using globals for database connections result from threaded applications, which are hardly ever done in php. Simultaneous requests are handled by different db-connetions usually. The way that most (popular) php based software does it, is it first creates a db-connection or otherwise dies. If during the course of the execution of the script the db becomes unavailable the script dies as well. The Connection is then closed at the very end of the script. Everything done in the script is sequential.

    Now using transactions or not, is whole other issue. Obviously if you are not using transactions, and the script dies after having done only half of the necessary updates, you will likely have a problem (inconsisten data); or if a simultaneous request respectively overwrite parts of the the newly made changes. This is basic database theory - and it has nothing to do with wether you use a global db-variable or a singleton (except maybe in very special circumstances).

    I would think that any risk posed by the above scenario would be ten times as dangerous with the use of persistent connections, since there's a pool of open connections that any script/request/process can use. Again, my understanding was that this was handled automatically, and that the same connection couldn't be used by more than one client at the same time. Am I mistaken in this point as well?
    A persistent connection is only used by one instance at any time. Or to quote from the manual:
    http://www.php.net/manual/en/feature...onnections.php
    In fact, to be extremely clear about the subject, persistent connections don't give you any functionality that wasn't possible with their non-persistent brothers.
    Their benefit is on a "different level" that has nothing to do with global var vs singleton. If you are using transactions with pconnects there are some caveats (due to side-effects), which are explained in the above link.

  14. #39
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    Singleton has advantages over a static class. For one thing it can have properties, so it may hold state (A connection-id for example).
    But a static class may have static properties, which means it can hold a state.

    Basically, a class that has only static members represents an application wide single object instance. The only difference is that the singleton makes it impossible to spawn multiple instances via the "new Class()" mechanism. With singleton, you can even do this:

    PHP Code:
    $aVariable = new SingletonClass();
    $aVariable->doSomething(); 
    and still be using the same, unique instance.

  15. #40
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    Please don't confuse object-oriented programming with software design-patterns. They may have spawned from the same place, but they deal with different abstration-levels. Most design-patterns can be implemented in whatever you want, though admittedly a few are pretty much tied in to object-oriented languages. (Such as the Singleton)
    *sigh* I don't mean to be rude but that really doesn't say much, does it? Further, I don't think it fairly characterizes my comments. Remember, I'm not arguing against OOP or OOP patterns nor am I trying to suggest that there is a one-size-fits-all coding style. My opinion is that in this specific case, a singleton, while it will do the job, is not as straight-forward as a static class. Looking back at my post I realize that I could and should have expressed my premise in a less confrontational style. For that, I apologize.

    Quote Originally Posted by kyberfabrikken
    Singleton has advantages over a static class. For one thing it can have properties, so it may hold state (A connection-id for example).
    Nothing prevents even a PHP4 static class from implementing private data in static function vars. It is much simpler with PHP5 since it does indeed support static class members. Again, I'm not arguing against singleton's in-general--I'm musing as to the benefit of them in this case. In my experience, singleton usage often occurs as a by-product of the fact that the language being used does not support non OOP styles. This is not the case for PHP. Still, I don't mean to be argumentative -- I have had my say so I will be good and be quite now.

    Greetings.

  16. #41
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I heard recently of someone who defined a constant with the database handle resource to provide global access through the application. Seems like this would work as long as you wanted to use the native API calls.

    The main benefit to using a Singleton pattern is guaranteeing the setup is done correctly on your single connection object instance. That said, if you don't really want an object, it may not be the way to go. Also, Singletons are effectivly stealth global variables, and can introduce testing headaches if you want to replace your connection object with a MockObject version during testing.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  17. #42
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    Singletons are effectivly stealth global variables
    The idea behind the Singleton is not about the scope of the instance, but the scope of the class. It is true that Singletons are by default global, but the pattern was introduced to be used when you need to ensure that a class may at any time have no more instances than one.

    Database connection is not necessarily the best candidate for singleton, because we may imagine a scenario where an application might have several database connections open at the same time (even in PHP, if we pulled the data from several db's, but especially in memory-resident applications) -- they can be singletons (but only if they belong to different classes), statics, globals, passed around as references or even instantiated anew on each call. A better example might be a HTTPRequest class representing the incoming request in a Web application: for each request -- which in PHP means for each run of the application -- there should be only a single request shared among all other classes.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •