SitePoint Sponsor

User Tag List

Page 4 of 9 FirstFirst 12345678 ... LastLast
Results 76 to 100 of 205
  1. #76
    SitePoint Enthusiast
    Join Date
    Apr 2004
    Location
    Berlin
    Posts
    25
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Oh i forgot to mention that Exceptions are a prime example of something that doesnt fit the PHP way at all!

    See my comments here for details:
    http://blog.thinkphp.de/archives/14-....html#comments

  2. #77
    SitePoint Zealot
    Join Date
    Mar 2004
    Location
    Milano
    Posts
    127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If the mayority of the people thinks that PHP5 is the right ambient for this application, I offer myself to maintain a PHP4 version of the same. I will not discuss the choices eventually made by the group, just making it compatible.

  3. #78
    SitePoint Enthusiast
    Join Date
    Apr 2004
    Location
    Berlin
    Posts
    25
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ponticelli
    If the mayority of the people thinks that PHP5 is the right ambient for this application, I offer myself to maintain a PHP4 version of the same. I will not discuss the choices eventually made by the group, just making it compatible.
    I will probably also end up on that side, as it will probably be impossible to get people on board to write a php5 only non exception using class that implements an object oriented pattern :-)

  4. #79
    Non-Member Musicbox's Avatar
    Join Date
    Nov 2004
    Location
    india
    Posts
    1,331
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Php 5 does the same thing that Php 4 does, the new version support new functions.

  5. #80
    SitePoint Enthusiast hantu's Avatar
    Join Date
    Oct 2004
    Location
    Berlin
    Posts
    54
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @lastcraft

    Spent my day thinking about that memory problem we have ... Please tell me if I understand it right:

    When pulling out lots of data, maybe even object graphs, we can't afford to keep the references and hashes/copies in memory needed by the Unit Of Work.

    We could provide an API where the user himself could tell the Unit Of Work not to save information about loaded objects and would have to care for registering the new/dirty objects to the Unit Of Work.
    But you stated there could be situations where the user won't be able to decide which objects need to be commited, so this is no viable solution.

    So a solution might be shared memory used by all concurrent requests running.

    Could you provide some more details about how you imagine this will work?

    Some open questions to me:
    • How often will a situation occur where a user couldn't decide which objects changed?
    • Do you plan to use this memory as a full object cache or only as a place to store information for the Identity Map and Unit Of Work?
    • Would we have to implement concurrency control for this shared memory? I guess we would
    • Would it be possible to make our software configurable whether to use shared memory or not? Or would the design impact of the decision to use it, be to big? If it worked only with shared memory, you wouldn't be able to use it in a shared hosting environment.

  6. #81
    SitePoint Enthusiast
    Join Date
    Apr 2004
    Location
    Berlin
    Posts
    25
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    is there a wiki setup yet to be able to hold a summary yet?
    if not I can quickly set one up ...

  7. #82
    SitePoint Addict
    Join Date
    May 2003
    Location
    Calgary, Alberta, Canada
    Posts
    275
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by hantu
    [*] How often will a situation occur where a user couldn't decide which objects changed?
    This is where Im stumped. I dont see the situation where evicting the persistent object from the IdentityMap would cause a huge problem. At the same time I dont see why you couldnt make a read-only session where the objects arent stored in the IdentityMap or UnitOfWork.

    Quote Originally Posted by hantu
    [*]Would it be possible to make our software configurable whether to use shared memory or not? Or would the design impact of the decision to use it, be to big? If it worked only with shared memory, you wouldn't be able to use it in a shared hosting environment.
    The ability to use this in a shared environment should be a priority.

    I think this is the direction we should be going. Take a page from Hibernate and have a IdentityMapStrategy, ReadOnlyStrategy and PersistentMemoryStrategy that is configured at the start of the session. The IdentyMapStrategy is the default. When we can build the PersistentMemoryStrategy we just enable the option.

  8. #83
    SitePoint Enthusiast
    Join Date
    Nov 2004
    Location
    Arizona, USA
    Posts
    94
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Brenden Vickery
    Take a page from Hibernate and have a IdentityMapStrategy, ReadOnlyStrategy and PersistentMemoryStrategy that is configured at the start of the session. The IdentyMapStrategy is the default. When we can build the PersistentMemoryStrategy we just enable the option.
    Bingo. My thoughts exactly. Abstract the different ways of tackling this problem using Strategy. It ultimately provides the flexibility to be used in a shared environment, as well as enhanced performance for those with control of their own boxes..

    And it makes sense from a development standpoint, too. Focus can move from "geez, how should we implement a persistent memory cache, we must have one..." to "let's define an interface for this Strategy", a far less "frightening" proposition..

    With a solid interface in hand, development of the "simpler" IdentityMap and read-only implementations could begin, and the likelyhood of project-killing stagnation is lessened.

  9. #84
    SitePoint Zealot
    Join Date
    Jun 2004
    Location
    Bogota
    Posts
    101
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Having in mind PHP's share nothing architecture I have to say that I don't know about the shared memory stuff. It's like it would need something implemented in C/C++ (maybe as an extension?), since obviously pure PHP won't cut it.

    If someone is willing to do such a thing I'll surely be here sitting in front of my computer waiting to be able to play with it, and maybe try and get involved somehow.
    If I have wings, why am I walking?

  10. #85
    ********* 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 hantu
    Could you provide some more details about how you imagine this will work?
    Sadly no, as I haven't yet tried to implement anything like this .

    Quote Originally Posted by hantu
    [*] How often will a situation occur where a user couldn't decide which objects changed?
    You pass the domain object to another method on another object to do some work...
    PHP Code:
    $session = &$authoriser($login); 
    Was the $login updated with any kind of usage statistics? Will it be updated in the future when the developers add more features?

    Quote Originally Posted by hantu
    [*]Do you plan to use this memory as a full object cache or only as a place to store information for the Identity Map and Unit Of Work?
    The minimum that works. Really just an object snapshot stashed by class and primary key.

    Quote Originally Posted by hantu
    [*]Would we have to implement concurrency control for this shared memory? I guess we would
    Yes . I'm not saying it's easy, but memory locking on a cache is way easier than the locking issues on a database.

    Quote Originally Posted by hantu
    [*]Would it be possible to make our software configurable whether to use shared memory or not? Or would the design impact of the decision to use it, be to big? If it worked only with shared memory, you wouldn't be able to use it in a shared hosting environment.
    As was mentioned later by someone way more knowledgeable than me, Hibernate does exactly this. This probably the way to go (especially as it allows incremental development).

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

  11. #86
    ********* 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 otnemem
    Having in mind PHP's share nothing architecture I have to say that I don't know about the shared memory stuff.
    It's a direct contradiction with the shared nothing vision. This comes back to having the different methods as strategies as was suggested, or running the cache as a Deamon so that updates can be transmitted to the other caches. Tools like Hibernate are for persisting complex object models which more likely the case for an involved web application, rather than a server farm driven presentational system.

    In contradiction to what I previously suggested, it strikes me you wouldn't be using a Hibernate like tool to iterate through a large result set. There are simpler tools for that type of job that would perform faster.

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

  12. #87
    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)
    Sorry to contribute so little direct content to this thread, but I did think of another possible name.

    Quote Originally Posted by lastcraft
    If you call it Phibernate then it will have to be a Hibernate clone, at least on the public interface.
    The fundamental idea of object persistance from this thread seems related to the term Object Graph. Taking that abreviation with everybody's favorite PH from PHP could yield a project name of PHOG.

  13. #88
    SitePoint Addict
    Join Date
    May 2003
    Location
    Calgary, Alberta, Canada
    Posts
    275
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    As was mentioned later by someone way more knowledgeable than me, Hibernate does exactly this. This probably the way to go (especially as it allows incremental development).
    Only knew to become knowledgable because you pointed it out as an issue.

    What do you guys think about how JDO does things:
    http://www.phptr.com/articles/articl...9515&seqNum=13
    A hollow instance is also a persistent object (it has a JDO object identity); however, its fields have not yet been retrieved from the datastore, hence the term "hollow." The first time that a hollow instance is accessed, its fields are retrieved from the datastore within the context of the current transaction and the instance transitions to being persistent. (It actually transitions to "persistent-clean" to indicate the instance hasn't yet been modified.) Likewise, by default, after a transaction ends, all instances that are persistent transition to being hollow.
    In other words: As soon as a UnitOfWork is commited, all cleanObjects fields are made null except for its id. If another transaction begins and that variable is used the object is loaded again from the database.

    Would making the objects "hollow" solve any of our problems or create more?

    Quote Originally Posted by sweatje
    The fundamental idea of object persistance from this thread seems related to the term Object Graph. Taking that abreviation with everybody's favorite PH from PHP could yield a project name of PHOG.
    I like that.

  14. #89
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The difference between JDO and Hibernate is mainly the difference between JDO-QL and HQL. HQL is SQL-like and JDO-QL is not. But, many JDO implementation support HQL these days.

    One way to clarify which way we want to go is to present some use cases and see what is the best fit.

    For me it is mostly cases where I have complex joins (3+ tables) bring data in and I may need to write back values to any or all of those tables. I want to focus my code on the task at hand, rather than dealing with the mess of tracking what needs to be written back.

    Finally, just thinking about a post back a ways about how to determine what is dirty and what isn't. What about explicitly specifying what is persistent via the naming of the properties. It may not be pretty but it might work. You could watch for changes in the properties that you want to be persistent instead of watching methods.
    class Employee {
    var $id;
    var $_persistent_pay;

    function setPay($pay) { ... }
    function getPay() { ... }
    function addYearlyRise() {
    $this->setPay($this->getPay() * 1.05);
    }
    }
    Christopher

  15. #90
    SitePoint Zealot sike's Avatar
    Join Date
    Oct 2002
    Posts
    174
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Brenden Vickery
    What do you guys think about how JDO does things:
    http://www.phptr.com/articles/articl...9515&seqNum=13

    In other words: As soon as a UnitOfWork is commited, all cleanObjects fields are made null except for its id. If another transaction begins and that variable is used the object is loaded again from the database.

    Would making the objects "hollow" solve any of our problems or create more?

    I like that.
    if we uses lazyloading all the way we should not need the "hollow" stuff. what i could think of is using the proxy pattern to retrieve objects where we don't need the whole object beeing intialized (e.g. when spitting out lists of items).

    cheers
    Chris

  16. #91
    SitePoint Enthusiast
    Join Date
    Apr 2004
    Location
    Berlin
    Posts
    25
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    PHP4 vs. PHP5
    Pondering the PHP4 vs. PHP5 topic some more I was seriously missing important aspects previously mentioned in this thread. Mainly Iterators and Reflections. Especially Iterators can probably help alot on the lazy loading front.

    Reflections will probably be more of a topic when its comes to round tripping from code to config xml.

    Memory
    The lazy loading stuff seems quite sexy in terms of memory consumption, but obviously means alot of queries who mainly fetch a single value. Unbuffered queries where the developer can flag certain data to remain in memory for fast access while traversing the entire result set might help there as a step between lazy loading everything. I guess the trick is in how to make this thing work for both large and small result sets.

    Also how to not end up doing a zillion queries as people one by one move down the member variables. Then again I dont really see how to do this properly. With all the caching going on you start to wonder why keep an RDBMS around at all? But that wasnt the intention of this thread I presume.

    I dont know if it makes sense to first ignore the memory issues and try to solve the other problems first and then trying out different ways of solving the memory issues at that point. Then again this might just as well lead us to throwing things out. But either way the hibernate devs must have solved these issues to some kind of level already. I dont know hibernate personally but after all they can be doing is caching things in the VM and I dont really see a way around doing the same or ending up with alot of little queries.

    I also dont know how hibernate intents people to scale, but usually Java guys tend to get nice fat boxes with alot of ram and cpu's, while us PHP folk tends to scale using multiple servers (shared nothing and all) and hook that up to some kind of (clustered) database setup. So taking that into account our scaling issues could be much greater than hibernates (briefly skimming the documentation index from the hibernate docs didnt reveal a topic that might behold the answers to how hibernate intents to scale).

    So all of this has me somewhat pessimistic as to our goals. It seems to me like its incredibly difficult to come up with a sensible (clusterable) caching mechanism without implementing a pretty sophisticated database system ourself. Eitherway that seems to be way out of the scope of this thread anyways so at best we should be looking at third party software to handle the storage part (eAccelerator and SRM do provide interfaces for shared memory) and I have vague memories of Derick at least pondering clustering support sometime in the long term for SRM.

  17. #92
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I dont think that we should try to deal with large result sets. Hibernate actually dissuades you from using it for things like large imports, etc. That's why I am interested in what people see are the real use cases.

    Christopher

  18. #93
    SitePoint Enthusiast
    Join Date
    Apr 2004
    Location
    Berlin
    Posts
    25
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ok thats also a valid strategy. What is your POV in regards to scaling across multiple machines? This seems to a bit harder to ignore ..?

  19. #94
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    I dont think that we should try to deal with large result sets.
    How large you you mean by "large"?

    Say I have a forum and want to list the top 100 posters along with excerpts from their most read posts. Would that be out of the scope of this RDBMS system?

    Douglas
    Hello World

  20. #95
    SitePoint Addict
    Join Date
    May 2003
    Location
    Calgary, Alberta, Canada
    Posts
    275
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    Say I have a forum and want to list the top 100 posters along with excerpts from their most read posts. Would that be out of the scope of this RDBMS system?
    That would not be out of the scope at all.

    Say you have 10,000 products in your database and you need to add/subtract a % to the price of each product. To do this you select all the products and then execute an update on each product.
    This sort of thing would be out of the scope.

  21. #96
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    How large you you mean by "large"?
    I think if you wouldn't want to iterate though, it is probably too large. I agree with Brenden that 100 is reasonable for a web app, but > 10k seems like you should use another mechanism.

  22. #97
    SitePoint Addict
    Join Date
    May 2003
    Location
    Calgary, Alberta, Canada
    Posts
    275
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lsmith
    So all of this has me somewhat pessimistic as to our goals. It seems to me like its incredibly difficult to come up with a sensible (clusterable) caching mechanism without implementing a pretty sophisticated database system ourself. Eitherway that seems to be way out of the scope of this thread anyways so at best we should be looking at third party software to handle the storage part (eAccelerator and SRM do provide interfaces for shared memory) and I have vague memories of Derick at least pondering clustering support sometime in the long term for SRM.
    I dont think we should be ignoring the memory or concurrency issues at all. They are important issues, especially in the more enterprise php applications. We know we have a problem and we're at that first stage where at least we can admit it . The thing is that the issue is not a show stopper but is a complex problem that I dont think any of us have a clear answer to.

    What are the available options? We have SRM with bananas. We have eAccelerator. Does the php-java bridge fit in here? How about the php extensions SHMOP or Memcache or Semaphore? Can we remove any of these or add any other possibilities?

  23. #98
    SitePoint Enthusiast
    Join Date
    Apr 2004
    Location
    Berlin
    Posts
    25
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Brenden Vickery
    I dont think we should be ignoring the memory or concurrency issues at all.
    I was more talking about delaying their resolution :-)

    Quote Originally Posted by Brenden Vickery
    What are the available options? We have SRM with bananas. We have eAccelerator. Does the php-java bridge fit in here? How about the php extensions SHMOP or Memcache or Semaphore? Can we remove any of these or add any other possibilities?
    Well none of these tackle the cluster problem for now. Then again we could leave clustering out of the scope for now :-)

  24. #99
    SitePoint Enthusiast hantu's Avatar
    Join Date
    Oct 2004
    Location
    Berlin
    Posts
    54
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    No posts here for the last days :'(

    There are still a lot of open questions regarding our project.

    I guess the topic to start would be the format of the metadata. We'd need a DTD or XMLSchema to define how the mapping will be described and furthermore a parser for it. And a strategy to cache the metadata (we don't want to parse the XML-File on every request).

    I think we need a mechanism to translate the metadata information into instances of certain descriptor classes (e.g. ClassDescriptor, AttributeDescriptor, AssociationDescriptor, ...) and cache those instances.

    The strategies for caching could be: cache the serialized object on the disk or
    use shared memory, if available.

    Furthermore we need a kind of Handler class that will detect whether the XML-file changed (if it changed, it needs to be parsed again) and lazy load the cached descriptor data.

  25. #100
    SitePoint Enthusiast
    Join Date
    Apr 2004
    Location
    Berlin
    Posts
    25
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    a DTD seems to be a bit too limited nowadays.

    As for caching of the metadata:
    I guess the big challenge is in managing the registry. The obvious solution is to store the metadata in array structures inside class's that represent the given entities that are generated once (and then again with every change). However this would mean that all possible entity-class's need to be loaded everytime on startup and be registered with the registry. In LiveUser I have one file with a giant array containing the entire structure (which could in theory be a cached representation of an XML structure):
    http://cvs.php.net/co.php/pear/LiveU...ge/Globals.php

    If we want to require the developer to manually execute the re-load or if we want to automatically do this is another question that can be delayed til the very end imho. In the end its just a convinience option, although I would say:
    - during development check if it needs to be regenerated
    - in production require manual regeneration (the cached represenation is likely to be just copied over from the staging server)


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
  •