SitePoint Sponsor |
|
User Tag List
Results 101 to 125 of 205
-
Feb 7, 2005, 08:49 #101
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by hantu
As for caching it, there is actually no point. By code generating the data mappers all of the information is converted to code anyway. You will need a generation step anyway to generate the schema scripts, so why not do as much processing as possible at that time ("currying"). Most of the example code posted on Sitepoint so far has used this process.
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Feb 7, 2005, 08:52 #102
- Join Date
- Apr 2004
- Location
- Berlin
- Posts
- 25
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Well my argument was that even if you generate all the code you may not want all the associated code to be loaded until you actually use it. Therefore it may make sense to not have to load the rest of the code to handle the given entity until you have determined you need it to make an instance of it.
-
Feb 7, 2005, 09:28 #103
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by lsmith
The real problems are determining how pure the object model will be and how much of the system tuning is exposed to the user. That dictates the complexity of the project. The level of sophistication if you will. Without some sort of mission statement to this effect you will run into a swamp of minor disagreements on how to do things. You cannot even write the first prototype without this.
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Feb 7, 2005, 09:30 #104
- Join Date
- Apr 2004
- Location
- Berlin
- Posts
- 25
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I agree .. that when it comes down to it what we are talking about atm are minor features that require no key structural decisions and as such qualify as premature optimization.
-
Feb 7, 2005, 10:25 #105
hi,
Originally Posted by hantu
cheers
Chris
-
Feb 7, 2005, 10:33 #106
- Join Date
- Oct 2004
- Location
- Berlin
- Posts
- 54
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
Originally Posted by lastcraft
PHP Code:
...
function generateInsertStatement ($object, $metaHandler) {
$desc = $metaHandler->getClassDescriptor(get_class($object));
$sql = 'INSERT INTO '.$desc->getTable();
$sql.= ' ('.$desc->getColumnList.') VALUES (';
// generate placeholders (?,?,?,?)
$sql.= implode(',', array_pad(array(), $desc->getColumnCount(), '?'));
$sql.=')';
$fieldDescs = $desc->getFieldDescriptors();
$i = 1;
$stmt = new PreparedStatement($sql);
// fill statement with object's values
foreach ($fieldDescs as $fieldDesc) {
$setMethod = 'set'.$fieldDesc->getType();
$getMethod = 'get'.$fieldDesc->getName();
$stmt->$setMethod($i++, $object->$getMethod());
}
return $stmt;
}
...
-
Feb 7, 2005, 10:38 #107
- Join Date
- Apr 2004
- Location
- Berlin
- Posts
- 25
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I got that part nicely covered inside LiveUser_Admin .. although I dont use prepared queries to handle proper quoting (I do ensure proper quoting though!).
Actually aside from the deficiencies I mentioned earlier about the limitations in regards to WHERE statement flexibility (I also mentioned this could be fixed by letting people pass Criteria Objects instead of simply arrays as filters) I think I have the query generation part done quite nicely there (well things like GROUP BY, self joins etc are also missing).
So maybe it would be a good idea to define what kind of queries we think would need to be possible to generate?
-
Feb 7, 2005, 16:35 #108
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
how pure the object model will be and how much of the system tuning is exposed to the user
Do we know up front that we want/need a pure the object model or little/no system tuning is exposed to the user?
If we start by saying that we can tolerate an messier object model and a good amount system tuning exposed to the user, does that get us farther faster?
Are we headed toward one or more prototypes? Or a toward what we think is the best shot?Christopher
-
Feb 8, 2005, 05:50 #109
- Join Date
- Mar 2004
- Location
- Milano
- Posts
- 127
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I don't know if that has been discussed before and I apologize in this case. My question is: have you considered to store serialized objects instead of ORM?
-
Feb 8, 2005, 06:28 #110
- Join Date
- Oct 2004
- Location
- Berlin
- Posts
- 54
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
Modern ORM Solutions
- Transparent Persistence
- Automatic dirty checking
- Transitive Persistence
- Inheritance mapping strategies
- Smart fetching and caching
- Development tools
Defining Transparent Persistence
- Any class can be a persistent class
- No interfaces have to be implemented
- No persistent superclass has to be extended
- Persistent classes can be used outside of the “persistence” context (Unit Tests, Batch Processing)
- Full portability without any dependency
Persistent classes
- JavaBean specification (or POJOs)
- Accessor methods for properties
- No-arg constructor
- Collection property is an interface (I don't understand this ...)
- Identifier property optional
Hibernate Query Language
- Make SQL “object-oriented”
- classes and properties instead of tables and columns
- supports polymorphism
- automatic association joining
- much less verbose than SQL
- Full support for relational operations
- inner/outer/full joins, cartesian product
- projection, ordering, aggregation and grouping
- subqueries and SQL functions
The slide can be found here: http://www.hibernate.org/hib_docs/on...atljug2004.pdf
-
Feb 8, 2005, 13:54 #111
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Yer, I got something much like what you've gone and posted about data persistence in a PDF?
The file is way too large for attachment thus I've not already attached it you seeI'll hunt it out again for anyone who wants me to email them it yes? Below is an actual copy and paste of some paragraphs from the PDF to clarify
A persistence layer encapsulates the behavior needed to make objects persistent, in other words to read,
write, and delete objects to/from permanent storage. A robust persistence layer should support:
1. Several types of persistence mechanism. A persistence mechanism is any technology that can be used
to permanently store objects for later update, retrieval, and/or deletion. Possible persistence
mechanisms include flat files, relational databases, object-relational databases, hierarchical databases,
network databases, and objectbases. In this paper I will concentrate on the relational aspects of a
persistence layer.
2. Full encapsulation of the persistence mechanism(s). Ideally you should only have to send the
messages save, delete, and retrieve to an object to save it, delete it, or retrieve it respectively. That’s it,
the persistence layer takes care of the rest. Furthermore, except for well-justified exceptions, you
shouldn’t have to write any special persistence code other than that of the persistence layer itself.
3. Multi-object actions. Because it is common to retrieve several objects at once, perhaps for a report or
as the result of a customized search, a robust persistence layer must be able to support the retrieval of
many objects simultaneously. The same can be said of deleting objects from the persistence
mechanism that meet specific criteria.
4. Transactions. Related to requirement #3 is the support for transactions, a collection of actions on
several objects. A transaction could be made up of any combination of saving, retrieving, and/or
deleting of objects. Transactions may be flat, an “all-or-nothing” approach where all the actions must
either succeed or be rolled back (canceled), or they may be nested, an approach where a transaction is
made up of other transactions which are committed and not rolled back if the large transaction fails.
Transactions may also be short-lived, running in thousandths of a second, or long-lived, taking hours,
days, weeks, or even months to complete.
5. Extensibility. You should be able to add new classes to your object applications and be able to change
persistence mechanisms easily (you can count on at least upgrading your persistence mechanism over
time, if not port to one from a different vendor). In other words your persistence layer must be flexible
enough to allow your application programmers and persistence mechanism administrators to each do
what they need to do.
6. Object identifiers. An object identifier (Ambler, 1998c), or OID for short, is an attribute, typically a
number, that uniquely identifies an object. OIDs are the object-oriented equivalent of keys from
relational theory, columns that uniquely identify a row within a table.
7. Cursors. A persistence layer that supports the ability to retrieve many objects with a single command
should also support the ability to retrieve more than just objects. The issue is one of efficiency: Do you
really want to allow users to retrieve every single person object stored in your persistence mechanism,
perhaps millions, all at once? Of course not. An interesting concept from the relational world is that of
a cursor. A cursor is a logical connection to the persistence mechanism from which you can retrieve
objects using a controlled approach, usually several at a time. This is often more efficient than
returning hundreds or even thousands of objects all at once because the user many not need all of the
objects immediately (perhaps they are scrolling through a list).
8. Proxies. A complementary approach to cursors is that of a “proxy.” A proxy is an object that
represents another object but does not incur the same overhead as the object that it represents. A
proxy contains enough information for both the computer and the user to identify it and no more. For
example, a proxy for a person object would contain its OID so that the application can identify it and the
first name, last name, and middle initial so that the user could recognize who the proxy object
represents. Proxies are commonly used when the results of a query are to be displayed in a list, from
which the user will select only one or two. When the user selects the proxy object from the list the real
object is retrieved automatically from the persistence mechanism, an object which is much larger than
the proxy . For example, the full person object may include an address and a picture of the person. By
using proxies you don’t need to bring all of this information across the network for every person in the
list, only the information that the users actually want.
9. Records. The vast majority of reporting tools available in the industry today expect to take collections
of database records as input, not collections of objects. If your organization is using such a tool for
creating reports within an object-oriented application your persistence layer should support the ability
to simply return records as the result of retrieval requests in order to avoid the overhead of converting
the database records to objects and then back to records.
10. Multiple architectures. As organizations move from centralized mainframe architectures to 2-tier
client/server architectures to n-tier architectures to distributed objects your persistence layer should be
able to support these various approaches. The point to be made is that you must assume that atsome
point your persistence layer will need to exist in a range of potentially complex environments.
-
Feb 8, 2005, 13:57 #112
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I think there are three things here: ORM, Persistence and HQL. I think the Persistence part is where the questions are at this point. The thing I am having a hard time clarifying is whether Hibernate style Transparent and Transitive Persistence is so much a part of JavaBeans and the application server that instead of trying to go that way in PHP you should just use Java? And if that is the case, then is there a "third way" to design a useful, PHP-style persistence layer on which to build the ORM/HQL parts?
Christopher
-
Feb 8, 2005, 14:00 #113
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Number 7 (Cursors) is off interest I'd think
-
Feb 8, 2005, 15:10 #114
Originally Posted by Dr Livingston
if not most of his writings are very usefull. in one pdf (and i thinks its the one you are speaking about) he describes the whole mechanics behind a persistence framework in enough details to base a framework on it. maybee its a good starting point.
cheers
Christian
ps. just finished a prototype of a query parser and the necessary meta descriptors including a sql builder. anyone interested in reviewing the code ?
if we work on some prototypes we might get a better grasp on what fits php best.
-
Feb 8, 2005, 15:28 #115
- Join Date
- Oct 2004
- Location
- Berlin
- Posts
- 54
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
For most things I develop, I consider PHP much more appropriate than Java because of its ease of use (no 'ant install' ... wait ... open browser ... wait until jsps are compiled ...).
The main disadvantage is that there is no comfortable way of persistence in PHP (I don't like handcoding SQL or using generated classes like propel's). And a transparent persistence tool would wipe out this last disadvantage.
-
Feb 8, 2005, 18:46 #116
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Sike,
Material for this White Paper has been excerpted from Scott W. Ambler’s books
Building Object Applications That Work,
Process Patterns,
The Object Primer 2nd Edition
and the
Design of a Persistence Layer Series
Software Development magazine, January through April 1998
Instead of emailing the PDF, I think there is a link to get a copy
http://www.ambysoft.com/persistenceLayer.pdf
Enjoy.
-
Feb 8, 2005, 21:46 #117
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
The main disadvantage is that there is no comfortable way of persistence in PHP (I don't like handcoding SQL or using generated classes like propel's). And a transparent persistence tool would wipe out this last disadvantage.
If this thing provided an HQL system and dealt with smart fetching and dirty cache writing, would that be enough? I see things like Propel as more of a convenience than an improvement.
Going back to Brenden's example (http://www.sitepoint.com/forums/show...9&postcount=39) is "persistence" really needed at all for the short PHP request/response cycle where the main goal is to just make sure that all data is read/written back.Christopher
-
Feb 9, 2005, 02:58 #118
- Join Date
- Oct 2004
- Location
- Berlin
- Posts
- 54
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
Originally Posted by arborint
-
Feb 9, 2005, 11:16 #119
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
What do you see as the difference between "all data is read/written back" and "persistence"? For me this means quite the same.
all data is read -> manipulate data -> all data is written back
To:
needed data is read -> manipulate data -> changed data is written back
For me this question is boiling down to: how to create a "comfortable" system that does not require generated classes. Comfortable means that creating Persisent classes is not too different from regular classes and not too much work. Can we agree on a definition of "too"?Christopher
-
Feb 9, 2005, 11:59 #120
- Join Date
- Oct 2004
- Location
- Berlin
- Posts
- 54
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
I totally agree.
Originally Posted by arborint
I'd say requirements for a persistent class should be a no-arg constructor and getters/setters for the fields including a field holding the PrimaryKey. And it shouldn't have to implement a certain interface or extend a certain base class to be persistent.
Would that be a definition you could agree on or do you imagine something different?
-
Feb 9, 2005, 12:33 #121
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Once you set some requirements you get rid of "every class can be persisted" which is fine my me. This gets back to my question that if you have to do this:
PHP Code:class Employee {
private $Pay;
function setPay($pay) { ... }
function getPay() { ... }
function addYearlyRise() {
$this->setPay($this->getPay() * 1.05);
}
}
PHP Code:class Employee {
private $persistent_Pay;
function addYearlyRise() {
$this->persistent_Pay *= 1.05;
}
}
Christopher
-
Feb 9, 2005, 13:18 #122
- Join Date
- May 2003
- Location
- Calgary, Alberta, Canada
- Posts
- 275
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
Does anyone know of another way to set/get access to a private variable?
The only reasons, IMO, to force a persistent object to implement an interface or extend a base class is if that is the only way to get an acceptance / performance test to pass. If either of these situations come into play, again the cost / benfits of the feature needs to be weighed against being able to persist any object.
-
Feb 9, 2005, 13:23 #123
- Join Date
- Oct 2004
- Location
- Berlin
- Posts
- 54
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
@arborint:
Sorry, but I couldn't get the point of your previous post. Could you provide some more details on what you're trying to accomplish?
-
Feb 9, 2005, 13:36 #124
- Join Date
- Oct 2004
- Location
- Berlin
- Posts
- 54
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Brenden Vickery
-
Feb 9, 2005, 13:46 #125
- Join Date
- May 2003
- Location
- Calgary, Alberta, Canada
- Posts
- 275
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by hantu
Quick example :
PHP Code:class Person {
private $firstname;
private $lastname;
public function __construct($f, $l) {
$this->firstname = $f;
$this->lastname = $l;
}
}
$person = array();
$person['firstname'] = 'Brenden';
$person['lastname'] = 'Vickery';
$person = cast($person, 'Person');
if($person instanceof Person) {
echo 'true';
}
// this echos true
Bookmarks