SitePoint Sponsor |
|
User Tag List
Results 26 to 50 of 121
-
Mar 8, 2006, 12:43 #26
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by BerislavLopac
More generaly speaking, I'll say that as a programmer, the api of a library is often equaly or more important as it's inner workings, since the api implies how I would have to work with it.
-
Mar 8, 2006, 12:46 #27
Originally Posted by kyberfabrikken
-
Mar 8, 2006, 12:46 #28
The same reason that ORMs in PHP don't see major community adoption is probably the same reason that PHP frameworks don't see major community adoption and the same reason that most PHP project's don't see major community adoption.
-
Mar 8, 2006, 14:15 #29
Originally Posted by thr
Obviously you have to learn what is expected and required in the XML document, but then again this applies no matter what approach you use for defining the mapping. Let's say you do it all in PHP code. You still have to learn how to do it... what methods to call, what variables to set. The only way you get to bypass learning how to configure the ORM is if it configures itself implicitly based on the database schema which isn't appropriate in many cases and brings with it a whole new set of problems.
Looking at your latest post in the "Feedback on current O/R Mapping Unittests" thread, I see that you describe an approach that expresses the configuration as PHP code, spread throughout the various finder classes. That seems like a workable approach, but I don't find it any less cumbersome than the XML approach. It still has to be learned and maintained. Perhaps you find that XML brings with it inherent complexities that the equivalent PHP code doesn't, and that's a valid opinion, but I personally don't share it.
Runtime introspection can be cached with ease so that's realy no problem.
Probably true there, but an ORM with bugs is much much much more serious then your avarage forum software - as other applications depend on the ORM to do it's job 100% correct.
I know they exists, but I think you agree on the fact that 95% of the php projects that use EZPDO/Propel just complicates thier problem further because they want to use a fancy solution on a simple problem, which is - yes - stupid.
You might think it's harsh and trivializes what work they've put into it, but I think some of thier design decisions are realy stupid - so why shouldn't I say so?
Edit: I realized I made a statement based on an assumption about your approach that was unfounded, and removed it, sorry.
-
Mar 8, 2006, 15:16 #30
- Join Date
- Oct 2004
- Location
- Worcester
- Posts
- 138
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I discarded Propel because of the build layer. I agree that the whole XML thing is a pain to as it's something else to learn. Clever code, but feels like a lot of work to get stuff done in. IMO Symfony suffers in this respect as you have to learn a lot of command line tools to use it.
I don't like the idea of doc block comments as it just feels wrong. Syntax checking is hard too. It's a clever solution to the problem though but again a new language has to be learnt.
I don't like the idea of database introspection as it feels like a lot of overhead for PHP's setup/teardown on each request system.
The simplicity of a table/row gateway where everything is essentially arrays of fields with helper functions is appealing. Also, SQL is fairly easy to pick up and tune.
As a counterpoint, I like the concept of defining the tables and relations in the PHP class. The downside of course is that you are either repeating what the database already knows or you have to make the PHP code maintain the database strucuture. In some ways letting the PHP code maintain the database structure appeals as it would save having to maintain database schema versioning and upgrade code.
*shrug* I know that I'm confused on this issue
That's why I'm following most of the ORM threads here and playing with Zend's simple Zend_Db_Table.
-
Mar 8, 2006, 17:24 #31
- Join Date
- Sep 2004
- Location
- Zagreb, Croatia
- Posts
- 830
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by kyberfabrikken
In other words, we must define what we want our tool to do. Take one of my above requirements as an example:
* has to use an already defined database, ie. the database must be independently accessible by other applications
It is very important to know whether our database should be accessible from other programs, who don't have the benefit of our ORM. Because if so, we should put more thought into the database design and normalization; if not, we can have a simple and universal database layout, which could be generated automatically and is dedicated to persist the objects in the simplest way (e.g. through simple serialization).
-
Mar 8, 2006, 17:50 #32
- Join Date
- Mar 2005
- Posts
- 31
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by BerislavLopac
-
Mar 9, 2006, 01:05 #33
Originally Posted by DerelictMan
Originally Posted by DerelictMan
Originally Posted by DerelictMan
Originally Posted by DerelictMan
Originally Posted by DerelictMan
Originally Posted by DerelictMan
Originally Posted by DerelictMan
Edit:
Reading my initial response to you now, I was a bit harsh and while I don't agree with many of the design decisions of propel my "stupid" statement was a bit.. stupid, from my side
-
Mar 9, 2006, 01:07 #34
Originally Posted by lftl
* Has to use an already defined database, ie. the database must be independently accessible by other applications - Check, Propel meets it
* No hand-written config files (if any are used, they should be automated), XML or any other format - No, propel requires .xml config files.
* Usable out of the box, at least for the simple cases (e.g. for single PK tables with up to one FK, which are most common on Web) -- no need to write complex table-classes before using it - No, propel requires definition and building of your objects and relations, I'd hardly say that's "out of the box".
-
Mar 9, 2006, 02:27 #35
- Join Date
- Nov 2005
- Location
- Croatia, Zagreb, Dubrava
- Posts
- 3
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I've built my active record implementation based on ADOdb, the code is still in progress of cleaning, but i can upload it somewhere if anyone is interested.
It uses language rules like in RoR Active record.
-
Mar 9, 2006, 06:38 #36
I'm realy starting to thinking about moving towards a TableDataGateway instead as it's much easier to work with, faster and allows for widget-style integration with Views, etc.
RowDataGateway + TableDataGateway, looking very much like Zends implementation but well... a bit different is realy starting to appeal. ActiveRecords seem to pull to much wieght and DataMappers always seem to either 1. pull imense amount of data(hit's performance) or 2. lazyload everything (hit's performance), ActiveRecord is nice, but it's to heavy and cluttered imho(yes I think RoRs AR is nice, but I don't like AR as a pattern).
-
Mar 9, 2006, 06:59 #37
Originally Posted by thr
If you don't want any special functionallity there's no need to create the "Person" class as it will be created automaticly at runtime for you - if you wan't other stuff in there go ahead and create your own, etc.
Maybe I should look at your code more closely before I make any more assumptions. I'll be watching the other thread...
Reading my initial response to you now, I was a bit harsh and while I don't agree with many of the design decisions of propel my "stupid" statement was a bit.. stupid, from my sideIt's been a good thread, regardless.
-
Mar 9, 2006, 07:02 #38
Originally Posted by DerelictMan
Originally Posted by DerelictMan
Originally Posted by DerelictMan
-
Mar 9, 2006, 07:03 #39
- Join Date
- Oct 2004
- Location
- Worcester
- Posts
- 138
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
As I understand it, an Active Record is just a Row Data Gateway with some domain logic in it.
The fun and games start happening when dealing with the relationships to the row that's encapsulated in the AR...
-
Mar 9, 2006, 07:07 #40
Originally Posted by akrabat
Originally Posted by akrabat
As I wrote above the problem is that either you're fetching to much or to little, both leading to performance issues when dealing with many requests / big requests.
-
Mar 9, 2006, 09:09 #41
- Join Date
- Mar 2005
- Posts
- 31
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by thr
Originally Posted by thr
I definitely understand, that's more work than some want to go through to get it up and running, but it's not the definition I was going by when I made my comment.
-
Mar 9, 2006, 09:12 #42
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
> So yes, a config file has to be created, but it doesn't have to be by hand.
It could be automated but does Propel allow for that automation though? I'm not sure where Propel stands in that regards
-
Mar 9, 2006, 09:22 #43
- Join Date
- Mar 2005
- Posts
- 31
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Dr Livingston
-
Mar 9, 2006, 09:34 #44
- Join Date
- Sep 2004
- Location
- Zagreb, Croatia
- Posts
- 830
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lftl
PHP Code:$table = new ORMTableWhatever('table_name');
$table->doTheMagic();
-
Mar 9, 2006, 09:51 #45
Personally I prefer:
PHP Code:$table->doKungFuMagic();
-
Mar 9, 2006, 10:39 #46
- Join Date
- Mar 2005
- Posts
- 31
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by BerislavLopac
Code:propel-gen creole; propel-gen om;
-
Mar 9, 2006, 12:06 #47
Originally Posted by BerislavLopac
-
Mar 9, 2006, 12:32 #48
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
> but I'd like that at least to be a modifiable setting.
I don't see personally, that there is a problem, but besides you can use whatever convention you like with Zends framework - read the documentation
-
Mar 10, 2006, 02:47 #49
- Join Date
- Jul 2004
- Location
- The Netherlands
- Posts
- 170
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I have never played with TableDataGateway. Someone care to provide some (pseudo) code examples?
-
Mar 10, 2006, 02:50 #50
Originally Posted by michel
Fowler uses a separate Person object for the PersonGateway, Zend_Db_Table uses a general Zend_Db_Row class instead. I'd say that Fowlers version looks very much like a simplified mapper. You can also use TDGs as a backend to your datamappers to encapsulate sql logic in one place.
Bookmarks