Blog: Propel2 Will Be an ActiveRecord Implementation Based On Doctrine2
Yesterday's IRC meeting was the occasion to design the shape Propel2, the next major iteration of the Propel ORM. The most important points resulting from the discussion are:
- Propel2 will require PHP 5.3
- It will be an ActiveRecord implementation (like Propel 1)
- It will be (mostly) backwards-compatible with Propel 1 - that means that the Query API introduced in Propel 1.5 is here to stay
- It will use code generation for better performance and IDE integration (like Propel 1)
- It will use Doctrine2 DBAL, and some parts of the Doctrine2 ORM, for internals
- The source code will be hosted on github
- I (François Zaninotto) will bootstrap and lead the project
- Everyone is welcome to contribute
I'm very happy with how things turned out. It seems that most people concerned with Propel saw the duplicated efforts in Propel and Doctrine as a waste of time. Propel2 will focus on the usability layer of the ORM, without the need to reimplement a DBAL, or an object-relational mapping layer.
See the complete discussion log after the break.
22:00:26 <francois> Ok everyone, it's 10pm on my watch, I guess it's time to begin
22:00:38 <Phenix> let's go
22:00:41 <francois> Letme first say (write) a few words
22:01:01 <francois> It's only been a year since I took over Propel, and I didn't expect to dedicate so much time to it
22:01:13 <francois> I didn't expect to make it move so much either
22:01:24 <grEvenX> :)
22:01:37 <grEvenX> (but oh has it moved!)
22:01:44 <francois> To be honest, I took Propel as a corpse, and gave myself the mission to help it have a soft death
22:01:54 <francois> today, that's not the question anymore
22:02:27 <francois> Propel is very much alive and has found (again) a community of users and developers
22:02:28 <b00giZm> (they call him the steve jobs of propel ;))
22:02:48 <francois> We could go on like this past year for a long time
22:03:33 <francois> adding killer feature every two days, refactoring the core without breaking BC, simplifying the life of developers
22:03:35 <francois> but
22:03:48 <francois> the future is not Propel 1.x
22:04:16 <francois> the future is probably Symfony2, Zend Framework2, Doctrine2, and all those Project2
22:04:27 <francois> So basically, we need a Propel 2
22:04:33 <francois> just for the sake of the number
22:04:37 <francois> (just kidding)
22:04:38 <StephenMelrose> :)
22:04:41 <avalanche123> :)
22:04:45 <LvanderRee> agree I can create a branch ;)
22:04:50 <grEvenX> hehe
22:05:10 <francois> When I took over the 1.x branch, someone else took over the 2.x branch
22:05:20 <francois> no work has been done on this branch since
22:05:33 <francois> So we are gathered here tonight
22:05:44 <francois> to discuss the future of Propel
22:05:58 <francois> what it should be, how it should be called, and who should take care of it
22:06:25 <francois> I suggest that we all talk together now to give our thoughts on the matter
22:06:32 <francois> because I'm feeling lonely :)
22:06:42 <francois> now shoot
22:06:50 <Jarda> I'm not completely sure if we really need a 2.0
22:06:57 <Jarda> you have done magical stuff with the 1.x branch
22:07:14 <grEvenX> there were some "bold" ideas a year ago, and even from earlier than that about what features should wait for Propel 2
22:07:19 <Jarda> there must be a killer vision for 2.0
22:07:26 <grEvenX> does anyone remember any of those suggested features?
22:07:28 <LvanderRee> I think we should cooperate more with doctrine in a new version
22:07:29 <StephenMelrose> But with more additions and BC 1.x becomes bloated. Doctrine2 is already amazing performance wise. Propel needs to step up to the place
22:07:46 <francois> Jarda: I'm sure we need it. People starting projects today, with PHP 5.3, namespaces, closures and late static binding will find Propel dated
22:07:54 <v-dogg> Criteria2 was meant to be the killer thing for P2 but current Query stuff is superior
22:07:56 <annismckenzie> I can only attest to the quality and thoughtfulness put into Propel 1.4 and up
22:08:01 <LvanderRee> using its dbal and other abstraction layers while still generating models
22:08:18 <tobiassjosten> francois: You have probably been asked the question before, but I'm relatively new to this scene, so... Why not join forces with the Doctrine crew? What does Propel bring to the table that Doctrine can't?
22:08:23 <b00giZm> francois, we already had a little email exchange about it. it's a real PITA to do unit testing with propel 1.x
22:08:48 <francois> ok, a few words about my view on Doctrine
22:08:55 <StephenMelrose> It's important to keep Propel and Doctrine seperate. Both push each other to innovate, imho
22:08:57 <lsmith> afaik the main thing differentiating doctrine from propel is code generation and the criteria API
22:09:02 <b00giZm> with doctrine it's really easy to use in-memory (sqllite) dbs, but with propel it's rally hard because of the generators
22:09:23 <francois> Doctrine 1 is fun the first time you use it, but it's too magical, too slow, and too hard to debug as compared to Propel
22:10:00 <LvanderRee> agree
22:10:02 <francois> Doctrine 1 gave a good boost to Propel, but now I think we shouldn't blush in comparison
22:10:03 <grEvenX> isn't Doctrine a "complete" framework? quite a few actually prefers to stay away from framework (or develop new ones)
22:10:07 <francois> As for Doctrine 2
22:10:13 <francois> It's a great library
22:10:32 <francois> that fills most of the holes and fixes most of the mistakes of Doctrine2
22:10:35 <tobiassjosten> Right, the magic is kind of scary. But speaking as a newcomer (honestly with no experience in Propel) I just feel there's wasted resources with these two awesome, but seperate, efforts.
22:10:41 <francois> but it has one very big difference with Propel
22:10:48 <francois> And with Doctrine 1, for that matter
22:10:57 <francois> It's not an ActiveRecord implementation
22:11:16 <StephenMelrose> And I like the AR implementation, which is why I use it
22:11:23 <nsolsen> me too
22:11:28 <francois> but the work done on the Doctrine DBAL is awesome
22:11:37 <francois> and SHOULD NOT be done a second time
22:11:42 <lsmith> francois: i am sure you read http://www.doctrine-project.org/blog/your-own-orm-doctrine2 ?
22:11:50 <francois> lsmith: yep
22:11:58 <b00giZm> oh...
22:12:02 <b00giZm> :)
22:12:20 <LvanderRee> I agree with tobiassjosten about wasting resources, and agree with francois about the magic and hard debugging and not active record, but as far as I know, doctrine2 is being very well designed, and we can build a active-record generator on top of doctrine's dbal
22:12:22 <francois> but ActiveRecord can be a master class all your entities extend
22:12:28 <LvanderRee> to share resources and effort
22:12:42 <francois> or abilities added by way of code generation
22:13:15 <LvanderRee> francois I think we are thinking the same ;)
22:13:24 <StephenMelrose> Why not build propel2 on top of doctrine2's DBAL then? If possible?
22:13:26 <lsmith> code generation approach could be made future proof with traits (http://wiki.php.net/rfc/horizontalreuse)
22:13:43 <francois> lsmith: when it's available
22:14:02 <Jarda> But if propel is going to switch to syntax like Doctrine_Query, I'll be out. It sucks donkeys balls..
22:14:06 <lsmith> right .. its already in trunk .. but no decision has been made on what the next php version will be
22:14:11 <francois> I know it's in the trunk/whatever the name of this PHP verion
22:14:25 <francois> I'm just not willing to wait for it
22:14:33 <francois> and it doesn't solve all problems
22:14:56 <lsmith> francois: oh i wasnt suggesting that .. i was saying .. care could be taken that once traits our out .. the code generation could switch to using traits
22:14:57 <francois> Jarda: That's a strong point
22:15:29 <francois> There is a strong difference between both Doctrine versions and Propel: the way to make queries
22:15:43 <Jarda> using Doctrine_Query is like writing raw sql, only it's much more PITA
22:15:53 <XpLo^bn> doctrine query api is very bad from my point of view
22:16:02 <XpLo^bn> well same as Jarda ~
22:16:07 <francois> I strongly believe that the Propel Query API provides a great architecture for model logic
22:16:19 <Jarda> francois: and an awesome IDE experience
22:16:27 <StephenMelrose> Seconded
22:16:30 <francois> Jarda: indeed, second strong point
22:16:33 <v-dogg> +1
22:16:44 <StephenMelrose> I adore that all the columns are constants. I hate using strings in Doctrine
22:16:49 <tobiassjosten> Right, there's some major differences in ORM implementation. :) But is there any difference in goal or approach (non-technical) between the two?
22:16:56 <Phenix> StephenMelrose: +1
22:17:01 <francois> tobiassjosten: I guess so
22:17:02 <lsmith> just FYI Doctrine 1.x and 2.x also provide a fluent interface, but the criteria API is definately a lot more complete
22:17:22 <francois> lsmith: Propel's Query API is more similar to rails' ARel
22:17:55 <francois> It's a real way to package your repository logic in a reusable and embeddable way
22:18:10 <francois> it's not just a magic interface to SQL
22:18:44 <francois> I was talking about the major difference in approach with Doctrine
22:19:32 <francois> I think Doctrine2 is very committed to following design patterns
22:19:39 <francois> sometimes too committed
22:19:53 <francois> And I also think that this can be counterproductive for the developer
22:20:02 <francois> IDE friendliness is an example
22:20:14 <francois> You can't achieve that with DQL
22:20:34 <francois> Propel's main goal is to make the life of developers easier
22:20:49 <francois> even if that means having not-so-perfect code insoide
22:21:01 <francois> At least that's the way I see it
22:21:11 <Jarda> +1
22:21:17 <francois> which is a good thing, since I'm quite a poor developer myself ;)
22:21:23 <grEvenX> haha
22:21:33 <LvanderRee> still ?
22:21:34 <LvanderRee> ;)
22:21:36 <annismckenzie> I think we all know that the main difference between Doctrine and Propel is code generation vs. no code generation. :)
22:21:36 <grEvenX> IDE sure helps me thorugh the day
22:21:39 <grEvenX> (and coffee)
22:21:40 <francois> That's also why the Doctrine2 guys seem to loathe ActiveRecord
22:21:44 <lsmith> using the Doctrine DBAL could already allow sharing a connection across plugins
22:21:56 <francois> lsmith: I'm all for it
22:21:57 <StephenMelrose> It should make life easier for the developer, yes, as long as the "not-so-perfect" code doesn't hinder performance
22:22:04 <lsmith> this would mean that it would be quite possible to mix and patch inside a single project
22:22:14 <francois> StephenMelrose: as of now, Propel is still faster than Doctrine
22:22:15 <lsmith> which would be of course a huge leap forward
22:22:18 <tobiassjosten> grEvenX: I can't stand IDEs. Been trying for the last decade but I can't come to odds with them.
22:22:47 <francois> tobiassjosten: Propel is also a lot faster with just a text editor
22:22:47 <annismckenzie> And that you can only provide good IDE support with generated code, especially with filterBy* methods and such.
22:23:00 <francois> It's one of the most concise ORMs
22:23:03 <grEvenX> tobiassjosten: I know your type! :P I just converted a long-time vim user to Eclipse :P
22:23:22 <francois> So, to sum up my vision
22:23:30 <francois> (and after that I let you guys talk)
22:23:30 <tobiassjosten> francois: Right, I was speaking more on the magic argument. Though I'm all for ditching magic still.
22:23:37 <b00giZm> i still prefer textmate over any kind of IDE, but as long as i can debug my code well, i'm fine. and that's really one thing i can't achieve with doctrine. so, you're right ;)
22:23:45 <StephenMelrose> I hate magic
22:24:04 <jwage> Sorry I missed things
22:24:10 <francois> Propel2 should be an ActiveRecord implementation built on top of Doctrine2 DBAL, using code generation to provide the same Query API
22:24:17 <francois> and one more thing
22:24:32 <francois> Propel2 should be backwards compatible with Propel 1
22:24:40 <LvanderRee> I don't think runtime speed is the MOST important issue (even for an ORM), development speed is.
22:24:42 <annismckenzie> Wait, what? :)
22:24:51 <StephenMelrose> IN what sense BC?
22:24:53 <annismckenzie> Awesome!
22:24:56 <b00giZm> whoaah
22:24:58 <b00giZm> :)
22:25:01 <LvanderRee> hi john nice to see you here as well
22:25:20 <lsmith> francois: hmm what would be the implication of using the EntityManager?
22:25:24 <francois> BC in the sense that code written for Propel 1 could still work with Propel 2
22:25:26 <StephenMelrose> LvanderRee: Erm, no. Runtime >>>>>>>>> Development
22:25:38 <StephenMelrose> francois: AH, you mean in the generated model?
22:25:41 <francois> lsmith: using the metadata classes as well
22:25:42 <StephenMelrose> I'm down for that
22:26:14 <francois> We've spent a long time defining a very usable API for both the ActiveRecord and the (Active)Query classes
22:26:18 <francois> let's not ditch that
22:26:25 <StephenMelrose> +1
22:26:30 <francois> BC is not an absolute goal
22:26:50 <LvanderRee> I don' t know about BC either. There are some serieus issues with Propel <1.3 regarding security (with the complex joins)
22:26:52 <greg1> francois: you mean «easy to upgrade to»
22:26:56 <annismckenzie> Now, francois could you tell us what the next killer feature you're constantly twittering about is in Propel 1.6? :)
22:26:59 <LvanderRee> breaking BC can fix those issues
22:27:03 <francois> it's just a guideline to say: we already have a good end user interface. Just make the thing better inside
22:27:23 <francois> LvanderRee: that could justify a BC break
22:27:34 <LvanderRee> OK than I agree
22:27:35 <francois> annismckenzie: Migrations
22:27:38 <StephenMelrose> Ah yes, joins. This is something we seriously need to visit.
22:27:45 <grEvenX> the only thing I currently don't see as "trivial" in the ModelCriteria is relatively simple queries with "and/or" (e.g. WHERE colA != 'B' OR colA = 'C')
22:27:46 <StephenMelrose> It's a pain in the add doing complex joins
22:27:51 <LvanderRee> stick as close as possible to the current API, which indeed is very nice!
22:27:59 <grEvenX> but I don't have any suggestions for improvement either
22:28:08 <annismckenzie> Yes!!! :) Thanks, francois!
22:28:14 <lsmith> francois: like i said basing things on the Doctrine DBAL is a great move, but i am not yet sure if it doesnt make sense to base the active record on the Doctrine ORM
22:28:20 <grEvenX> (and improvements could still be done there I guess without breaking BC)
22:28:22 <b00giZm> the query api is great, but BC with the old criteria crap? oh lord...
22:28:27 <LvanderRee> We aren't it calling 1.x for reason, BC can be broken (although preferably not of course, to keep upgrading easy)
22:28:36 <francois> lsmith: we can use some parts
22:28:44 <francois> b00giZm: no way
22:28:48 <greg1> LvanderRee: +1
22:28:53 <b00giZm> THANKS! :)
22:29:03 <lsmith> but i have another point to bring up .. unit testing .. i dont have that much experience with propel, but in the code i have seen .. there are a lot of static method calls
22:29:12 <greg1> otherwise, what would be differences between Propel 1.6 and Propel 2.0 ?
22:29:13 <francois> lsmith: no anymore
22:29:16 <lsmith> which can make unit testing harder .. is that addressed via code generation?
22:29:25 <lsmith> ah ok
22:29:46 <francois> Propel 1.6 currently has 3785 unit tests
22:29:56 <francois> it's not hard to test at all
22:30:01 <annismckenzie> :O
22:30:10 <lsmith> well i am more talking about unit testing my model business logic
22:30:16 <francois> 'static' is so Propel 1.3 ;)
22:30:26 <lsmith> without having to have a db running
22:30:32 <francois> lsmith: well, you need a storage for that
22:30:38 <LvanderRee> lsmith this was the case with peer caslles, now there are queries
22:30:41 <francois> even if it is a test storage
22:30:44 <lsmith> which requires introducing mock query instances for example
22:30:44 <grEvenX> lsmith: setup sqlite storage?
22:30:57 <francois> lsmith: if you use Symfony, you can have different storages for prod and dev
22:31:02 <lsmith> but if the static calls are gone .. its all good :)
22:31:03 <b00giZm> @grEvenX that's not trivial for propel 1.x
22:31:22 <b00giZm> i've been through this ^^
22:31:23 <francois> b00giZm: it is within symfony
22:31:41 <grEvenX> b00giZm: what's the issues with it? ( I never tried )
22:31:43 <francois> lsmith: about your question on reusing Doctrine ORM
22:32:08 <Jarda> b00giZm: I've used propel with sqlite, no problems at all
22:32:29 <francois> I think we could reuse the XML/YAML/Annotation drivers and metadata classes
22:32:38 <b00giZm> @Jarda - mysql for dev/prod AND sqlite for testing?
22:32:42 <b00giZm> tell me about it :)
22:33:03 <francois> As for persisters, Proxies, and Queries, Propel would have a different approach
22:33:09 <Jarda> b00giZm: I hate mysql from the bottom of my heart :)
22:33:14 <annismckenzie> francois: Where do you want to start with the change to the Doctrine DBAL? And when — and who? Those are a few things you wanted to talk about today.
22:33:34 <francois> eventually, code generation should lead to SQL code generation, and the speed that comes with it
22:33:48 <XpLo^bn> we use sqlite with propel 1.3 since 1 year in prod with embeded java program transfering the sqlite file to the php server without any prob (something like 5000 user)
22:33:54 <grEvenX> well, it for sure would have to be someone allready familiar with the Doctrine stuff I would say :P
22:34:06 <grEvenX> at least, that's a big +
22:34:07 <francois> annismckenzie: indeed
22:34:15 <XpLo^bn> so no problem there
22:34:34 <lsmith> i agree that with the approach you layed down for Propel2 .. you want to do the SELECT SQL generation yourself
22:34:38 <francois> but first, does anybody feels not comfortable with the directions I wrote earlier?
22:34:46 <Jarda> but as I see it, starting to write propel 2.0, would mean development on 1.x should be at least slown down a bit. You can't rewrite and keep up at the same time :)
22:34:54 <francois> lsmith: indeed. No DQL in Propel
22:34:58 <lsmith> and Doctrine ORM allows you to use plain SQL and map back to Entities
22:35:19 <francois> lsmith: That's what we would keep
22:35:47 <LvanderRee> francois I had the same idea, so very comfortable +++
22:35:49 <jwage> Have things in Doctrine ORM been properly evaluated?
22:35:52 <lsmith> but i dont see any reason at first sight .. why the Entities themselves cannot be Doctrine ORM Entities .. simply with code added to them during the code generation
22:36:06 <jwage> I mean, are you sure that the things you want to do cannot be accomplished using the ORM components?
22:36:15 <lsmith> which would also allow you to prevent DQL to be triggered for lazy loading properties etc
22:36:15 <grEvenX> francois: could you pinpoint some of the benefits of using parts of Doctrine 2 (for those not familiar with the framework)
22:36:23 <tobiassjosten> francois: I still feel it's a shame that all these brilliant people are working in two different projects. But I digress, I have too little experience in Propel.
22:36:25 <Jarda> so the decision on starting with 2.0 must be something people are commited to. We can't risk on stopping to develop 1.x if nothing happens in 2.0
22:36:29 <jwage> Because I've been reading through the logs here and all the things francois wants to do is totally capable on top of the ORM components.
22:36:59 <francois> jwage: It's kind of what we are talking about :)
22:37:04 <lsmith> jwage: i think its clear that they really dont want to go through the DQL layer .. but i think thats totally supported by the ORM
22:37:07 <jwage> you're not forced to use DQL so the code completion and such is not an issue
22:37:40 <jwage> it would be possible to have the Propel Query API generate Raw SQL
22:37:44 <jwage> and a ResultSetMapping
22:37:45 <LvanderRee> jwage good point
22:37:55 <LvanderRee> and you should probably know ;)
22:37:59 <francois> jwage: that's what we've been saying earlier
22:38:00 <lsmith> to me Propel would basically enrich Doctrine 2.x models with the code necessary to generate SQL straight
22:38:02 <jwage> and this can be used to let Doctrine DBAL fetch the data and Doctirne hydrate the data and entities
22:38:07 <jwage> lsmith: exactly
22:38:11 <jwage> it is just yet another abstraction
22:38:23 <jwage> Doctrine ORM is a much lower level abstraction to object persistence than something like active record
22:38:32 <jwage> so instead of trying to fit both of these levels of abstraction in one library
22:38:37 <annismckenzie> I smell a new project added to the Doctrine Jira named "PropelExtension".
22:38:38 <jwage> it should be layers, AR goes on top of this
22:38:59 <francois> jwage: yep
22:39:06 <b00giZm> weren't we kinda talking about that all the time? i'm confused...
22:39:10 <jwage> so Propel can give a very rich and deep UI for development
22:39:10 <francois> except that sometimes, a layer on top should go under
22:39:16 <francois> letme explain
22:39:29 <lsmith> francois: with the code generation i presume you also get around having to use a common base class, which is an annoying side effect of many PHP AR implementations?
22:39:43 <francois> lsmith: not necessarily
22:39:53 <francois> actually, the Propel BseClass is quite small
22:39:55 <jwage> i don't uderstand why it has to be ActiveRecord.
22:40:00 <jwage> you can give the same rich Query API and everything
22:40:03 <jwage> without it being ActiveRecord
22:40:10 <XpLo^bn> one of the reason i didnt use doctrine was the unsupported composite foreign key in 1.x, it seems it s still not supported in 2.x, so i wouldnt really like a propel on top of doctrine ~
22:40:12 <jwage> you can maintain transparency and still offer the rich UI goodies
22:40:32 <StephenMelrose> Please don't ditch ACtiveRecord!
22:40:42 <StephenMelrose> It's the main reason I use Propel
22:40:43 <lsmith> XpLo^bn: yeah .. its still an open issue .. to be addressed in 2.1 .. but its sure is important!
22:40:44 <francois> jwage: Propel2 will be an ActiveRecord
22:40:53 <francois> some people, like me, prefer that
22:40:57 <jwage> the only difference is where you call methods to persist an object right?
22:40:58 <Jarda> jwage: I like my $model->save(), $model->delete() etc :)
22:41:01 <jwage> or what am I missing?
22:41:12 <jwage> it is a bottle neck too for batch operations
22:41:18 <Jarda> I hate doing "$manager->delete($model);"
22:41:25 <jwage> multiple ->save(), ->save() versus one ->flush() call
22:41:39 <jwage> one flush is faster for lots of objects than multiple ->save calls
22:42:12 <francois> ActiveRecord provides sevral features directly to the Entity classes
22:42:23 <jwage> you have some other methods? like toArray()
22:42:25 <jwage> and some other stuff?
22:42:45 <lsmith> jwage: well i do think that Propel probably should stick with AR, but of course underneath it could use the Doctrine EntityManager
22:42:47 <greg1> Model::save(array($obj1, $obj2 ...))
22:42:48 <jwage> so the difference is calling the methods on the objects instead of passing the objects to methods on another object
22:42:50 <francois> like the ability to persist/delete/detach themselves, validation, the ability to be transformed into XML or JSON
22:42:54 <francois> and most of all
22:43:01 <francois> ActiveRecord allows for behaviors
22:43:17 <jwage> hmm its not necessary if you have code generation though
22:43:19 <grEvenX> +1 for not ditching AR
22:43:33 <francois> jwage: that's what I was trying to explain
22:43:39 <francois> but you keep stopping me
22:43:43 <francois> please
22:43:57 <francois> What we could do with code generation
22:43:59 <lsmith> having the call on the model itself simplifies some things .. of course it comes with its own bag of limitations .. especially when one needs to do multiple things inside a transaction
22:44:06 <francois> is to generate base classes for Entities
22:44:16 <francois> not extending a single BaseClass
22:44:26 <lsmith> +1
22:44:30 <francois> but carrying intelligence
22:44:31 <jwage> agreed
22:44:42 <ZaraXVI> uh
22:44:55 <francois> the BaseEntity could itself extend another class, allowing for real class inheritance
22:45:17 <ZaraXVI> you're going to go into runtime introspection like doctrine rather than code generation ?
22:45:20 <francois> the BaseEntity would be regenerated with each storage/model change
22:45:32 <francois> ZaraXVI: nope, quite the opposite
22:45:38 <ZaraXVI> ah
22:45:42 <ZaraXVI> j'ai eu peur
22:45:43 <francois> Propel has a generation phase, that's what makes it fast
22:45:48 <ZaraXVI> yea
22:45:51 <francois> let me explain how I see things
22:45:57 <ZaraXVI> that's why i choose propel ^^
22:46:02 <lsmith> ZaraXVIII: its similar to what traits its doing on the engine level, but copying code into the model class
22:46:14 <francois> 1 - you create an entity class that extends nothing. A POPO, as they say
22:46:20 <lsmith> into each model class
22:46:21 <francois> lsmith: exactly
22:46:34 <francois> 2 - you add mapping with whatever driver you want
22:46:48 <francois> 3 you launch AR generation, and it does two things:
22:47:08 <francois> 3.1 : it generates a BaseEntity for your Entity, extending nothing
22:47:21 <francois> 3.2 it modifies your entity to make it extend BaseEntity
22:47:43 <francois> Now you have a usability layer on top of your Entity, but in fact it's underneath
22:47:57 <francois> It's Doctrine's Proxy classes taken from the other way around
22:48:06 <francois> Is it clear?
22:48:16 <grEvenX> sounds good to me
22:48:21 <b00giZm> sounds smart :)
22:48:25 <francois> Now take the same idea
22:48:33 <francois> and apply it to Doctrine Repositories
22:48:39 <lsmith> so the BaseEntity is something the user will never touch with his own hands
22:48:42 <francois> and you have PropelQueries
22:48:57 <francois> lsmith: indeed, the code still goes to the entity class
22:49:21 <annismckenzie> Hmm, I'm probably a bit slow today so if someone could explain that to me again, I'd be very glad (what francois just said).
22:49:27 <jwage> francois: would it be possible to have a sort of traits/multiple inheritance feature in the code generation
22:49:43 <francois> jwage: that's what we already have in Propel 1 with behaviors
22:49:47 <francois> and sure, that's a must
22:49:54 <jwage> but i mean literally write another class
22:49:59 <jwage> and have a syntax to include that class
22:50:01 <jwage> and it copies the code
22:50:04 <lsmith> jwage: i suggested that the code generation should probably be made forwards compatible to be partially replaced by traits once they are available
22:50:13 <jwage> is that what you mean?
22:50:16 <francois> jwage: not sure I understand
22:50:39 <francois> annismckenzie: it's just like Propel 1, except that instead of starting with a schema, you start with the stub classes
22:50:52 <jwage> imagine in your mapping for a propel entity you could say i want to import the code from another class that is mapped as a trait
22:51:03 <francois> annismckenzie: in the end, you still manipulate ActiveRecord and ActiveQuery instances the same way
22:51:19 <jwage> during the code generation phase it would literally open the class and copy the contents of the class in to the generated base entity for that model
22:51:20 <francois> annismckenzie: we're just discussing the implementation details
22:51:34 <jwage> so it would be exactly like what traits are just done at code generation time
22:51:36 <Yrwein> francois__ Would be possible then do add (through configuration) class that will be extended by generated class (generated class will have "extends MyBaseEntityClass")? If I understand that well... -> F. e. for adding features common to all entities.
22:51:42 <weaverryan> you all started a bit early didn't you ;)
22:51:45 <francois> jwage: Behaviors already do that, but they do a lot more
22:51:53 <annismckenzie> weaverryan: You're late! :)
22:52:04 <francois> jwage: like generating directly the right method names, to avoid relying on magic methods
22:52:29 <lsmith> Yrwein: i think what francois is explaining here a way to be able to add any functionality you want into a class without having to use a common base class
22:52:33 <annismckenzie> Thanks francois, I think I got it now. :)
22:52:34 <lsmith> since the code is copied
22:52:49 <lsmith> but of course you are free to still force a common base class
22:52:53 <francois> Yrwein: it would be possible, yes, but lsmith wouldn't be happy ;)
22:53:39 <grEvenX> jwage: sounds smart
22:53:42 <francois> One small detail: I think the discussion focuses too much on the AR classes, while Propel's most distinctive features come from the Query API
22:54:12 <lsmith> francois: by using the EntityManager underneath you could use Doctrine ORM for all writes
22:54:23 <Yrwein> lsmith, fancois__: Ok then. .)
22:54:27 <francois> And using the same code generation principles, we can make Doctrine Repository classes extend a BaseRepository class, with all the smart filetrs and so on
22:54:42 <francois> lsmith: yes, I agree
22:54:51 <lsmith> which would be kind of cool .. because then i could easily switch to using the Doctrine ORM API in case i need to do something complex in terms of transactions
22:55:01 <francois> lsmith: indeed
22:55:16 <lsmith> ok sounds awesome to me! :)
22:55:18 <LvanderRee> weaverryan, you missed the new feature for 1.6: migrations, but the real discussion is about the future of prope, (propel 2.0) the idea is to use Doctrine 2.0 but add generators on top of it to allow fast development (IDE completion), and fast runtime
22:55:34 <LvanderRee> weaverryan: details are currently being discussed, with jwage
22:55:34 <weaverryan> great, thanks LvanderRee :)
22:55:52 <jwage> francois lsmith: http://pastebin.com/wWFpUSDP
22:55:59 <jwage> to make sure we're saying the same thing this is what I am thinking
22:56:01 <jwage> pseudo code
22:56:07 <Jarda> francois: but I'm actually against defining schemas via stub classes.. I like my xml configuration..
22:56:20 <lsmith> i like DQL, but i think this is sounding like it really brings what makes Propel 1.x unique into a system that makes it easy for users to mix and match Propel/Doctrine code
22:56:24 <weaverryan> if propel were built on top of Doctrine ORM, wouldn't that mean that bundles could be made to work with Doctrine or Propel just by being sure to only rely on the lower-level Doctrine ORM functionality?
22:56:29 <jwage> Jarda: using Doctrine you would be able to do it either way
22:56:37 <Jarda> jwage: ok, great
22:56:42 <jwage> weaverryan: that is correct
22:57:18 <jwage> so you can map some entities, and say this entity uses this other mapped trait
22:57:24 <jwage> and during code generation it copies the code
22:57:28 <jwage> is that what propel behaviors does currently?
22:57:31 <weaverryan> woh
22:57:59 <lsmith> francois: i guess going by the code generation to enable IDE mantra .. are you considering annotations?
22:58:07 <lsmith> or do you prefer explict API calls
22:58:19 <jwage> of course just like traits or multiple inheritance you can have conflicts but that is normal
22:58:28 <francois> jwage: see my version http://pastebin.com/eQ0XaBSV
22:58:51 <annismckenzie> Ah, weaverryan, one thing you really did miss: Propel 2.0 will try to be BC with Propel 1.x!
22:58:54 <jwage> what does the BaseA provide?
22:59:14 <jwage> the AR implementation?
22:59:21 <francois> jwage: yep
22:59:27 <francois> a lot of code not in the example
22:59:36 <jwage> ya
22:59:37 <weaverryan> annismckenzie: oh wow - that's definitely important
22:59:49 <ZaraXVI> i don't get what all those ideas will bring
22:59:52 <francois> lsmith: I don't understand
23:00:00 <jwage> i cant wait until we have traits
23:00:03 <jwage> and this wont be an issue anymore
23:00:09 <jwage> hehe
23:00:09 <francois> jwage: and same for the ARepository class
23:00:34 <francois> jwage: traits won't solve all the problems Propel behaviors solves
23:00:41 <lsmith> francois: so you are planning to adopt annotatins for propel 2.0?
23:00:54 <lsmith> francois: hmm your code looks a lot like http://wiki.php.net/rfc/horizontalreuse#grafts_-_class_composition_not_implem...
23:01:01 <francois> lsmith: I think the user can define the mapping the way she wants
23:01:13 <francois> whether using annotations, or any other supported format
23:01:23 <lsmith> which is the alternate approach discussed for horizontal reuse .. in the end php.net went with traits .. which is more like what jwage's pseudo code is
23:01:25 <annismckenzie> lsmith: It doesn't matter with all the mapping converters available for Doctrine 2.
23:01:46 <jwage> ya you can specify mapping in anything
23:01:50 <francois> lsmith: grafts provide more features that traits, yes
23:01:56 <jwage> so you can looad the mapping whether it is via xml, yaml or annotations
23:02:01 <jwage> and use the mapping info to do the code generation
23:02:46 <lsmith> i obviously agree that you cannot wait for trunk to be released, but i am not sure it makes sense going a different route ..
23:02:54 <francois> ok, seems that we agree on the main principles. It's maybe not the time to decide the final implementation, though :)
23:03:12 <lsmith> yeah
23:03:25 <francois> lsmith: look at Propel behaviors and tell me if you can do the same things with traits
23:03:43 <francois> I'm sure you'd end up with a lot of __call() and runtime overhead
23:03:53 <ZaraXVI> much more down to earth, is their a graphical editor that can generate xml or yml schemas for propel ?
23:03:59 <francois> And no IDE completion
23:04:08 <arlo> correct me if i'm wrong, we can have the domain model pattern of Doctrine, with some of the characteristics of an Active Record implementation (persistance directly available in the object), and with a fluid query interface on both objects and repository ?
23:04:09 <francois> ZaraXVI: yes
23:04:19 <ZaraXVI> francois: which one ?
23:04:42 <francois> ZaraXVI: http://www.orm-designer.com
23:05:12 <francois> arlo: what do you mean fluid query interface on object?
23:05:20 <ZaraXVI> uhuh
23:05:23 <ZaraXVI> "buy now"
23:05:30 <annismckenzie> :)
23:05:42 <arlo> (Active)Query : right, it's not really on object
23:05:46 <v-dogg> (not everything can be free)
23:05:56 <lsmith> francois: well i am sure once traits are released they will get IDE support
23:05:58 <francois> arlo: that's the principles, yes
23:06:10 <lsmith> but yes traits as they are in trunk are essentially just engine level cut&paste
23:06:13 <lsmith> and they are stateless
23:06:16 <lsmith> http://wiki.php.net/rfc/horizontalreuse#traits_vs._grafts
23:06:25 <francois> lsmith: which is their limit
23:06:28 <ZaraXVI> well, i'd like a free one :)
23:06:28 <LvanderRee> I think I want to see/implement some things based on the ideas we agree on and then look further about how to specifically solve things. But for now the idea seems to be to extend not only the Doctrine2 Dbal, but also the ORM and add a Propel layer on top of that, isn' t it
23:06:43 <francois> LvanderRee: yes
23:06:43 <LvanderRee> so use Doctrine2 with its entities, and entity manager
23:06:46 <lsmith> so sure in a lot of cases a trait method will have to make an instance of something to be able to implement what you need
23:07:12 <francois> lsmith: let's discuss this some other time
23:07:27 <lsmith> francois: yeah .. btw the guy who wrote the RFC is nice and approachable
23:07:31 <lsmith> but tends to be busy at times
23:07:43 <Jarda> hey, it's getting very late
23:07:43 <lsmith> but i would recommend also asking him for advice
23:07:53 <Jarda> we are in too much detail talk atm
23:08:15 <lftl> ZaraXVI: there are a couple of option in the free department that just use XSL to transform XML output from other GUI DB design programs
23:08:25 <francois> So now that we (kinda) agree on the face of Propel2, there are more questions arising
23:08:26 <francois> Who is interesting in contribiuting?
23:08:33 <Jarda> couldn't we maybe start talking whether we start doing propel 2.0 and who will commit to developing it?
23:08:48 <francois> Jarda: :)
23:09:03 <francois> Who wants to contribute?
23:09:17 <Phenix> francois: me
23:09:25 <b00giZm> i smell something big ;) i guess i'll give it a try, francois :)
23:09:46 <ZaraXVI> hmmm
23:09:58 <LvanderRee> francois I am as long as I am still developping in php ... ;)
23:10:03 <Jarda> as I said earlier (it might have drowned in the noise) we can't do heave development in two completely different branches if we don't want to loose features in 2.0
23:10:06 <grEvenX> I still haven't got this, can somebody please explain the main benefits from me as a Propel user to use Propel 2 ? And the benefits of using Doctrine 2 in this, is it for the Propel devs or for the user (or both)
23:10:18 <Phenix> I am interested in propel
23:10:29 <Jarda> *heavy
23:10:42 <annismckenzie> Please francois, get Propel2 on
23:10:43 <grEvenX> I can contribute, and get specific task, but I will not be able to take on managing this project
23:10:52 <francois> grEvenX: access to all PHP5.3 features
23:11:05 <francois> grEvenX: ability to use Doctrine bundles/projects
23:11:16 <LvanderRee> francois I have some time tomorrow already, I can see what I can do then, but I am thinking about switching to Python as my main development language....
23:11:16 <francois> grEvenX: Even more speed
23:11:22 <grEvenX> (that we like)
23:11:30 <francois> LvanderRee: great language, bad idea
23:11:58 <annismckenzie> Damn. Again. francois, could you put development of Propel2 onto GitHub? That would make contributing easier for all of us.
23:12:10 <grEvenX> francois: thanks for making those things clear :)
23:12:11 <francois> annismckenzie: definitely
23:12:17 <weaverryan> excellent :)
23:12:21 <b00giZm> great :)
23:12:37 <lsmith> francois: i have my hands in all sorts of other stuff already .. but you can always ask me in case there are questions about RDBMS differences and other nitty gritty SQL details
23:12:52 <francois> lsmith: great, thanks
23:12:56 <grEvenX> I guess I'd have to read francois tip on that git "tutorial" then
23:12:57 <grEvenX> :P
23:13:09 <annismckenzie> :D
23:13:23 <lsmith> http://progit.org/book/ !
23:13:28 <francois> oh, one last thing
23:13:33 <b00giZm> you'll like it
23:13:51 <lsmith> b00giZm: he is really the steve jobs of propel :p
23:13:51 <francois> What name shall we give to Propel2?
23:14:05 <b00giZm> Proptrine :D
23:14:05 <b00giZm> just kiddin
23:14:08 <annismckenzie> Definitely! If you take a look at how contributions are handled in Symfony2 you'll notice how much more open development becomes with git.
23:14:41 <Jarda> francois: are you going to take the initiative with Propel2? Or should there be a vote of some kind of the lead?
23:14:47 <annismckenzie> Doctrel? :D
23:15:05 <francois> Jarda: If someone feels strong enough to take the mead, I'd be delighted
23:15:09 <francois> s/mead/lead
23:15:25 <francois> I already have too much work with Propel 1
23:15:29 <Jarda> (I can't think of anyone else leading the development, but well.. I'm happy with 1.x and don't feel the need of P2)
23:15:41 <ZaraXVI> git *blurp*
23:15:56 <francois> Anyone here wants to lead Propel2?
23:16:18 <grEvenX> people will have to step up for them selves if they think they can take the lean on Propel 2 (because no-one here know who you are and can "promote" you anyway)
23:16:18 <grEvenX> :P
23:16:32 <annismckenzie> Uh oh, silence.
23:16:36 <Jarda> +1 for changing to git also for 1.x branch, but I'd like to have an up-to-date svn mirror also for externals (the svn:externals from github doesn't work well..)
23:17:12 <francois> Jarda: We'll update the git mirror, but I think Propel 1.x will keep SVN
23:17:36 <ZaraXVI> what's with git
23:17:47 <annismckenzie> Jarda: it works pretty well but you're right in that there can only be a master branch accessible through svn.
23:17:48 <francois> ok, so I'll boostrap Propel2 in my github account
23:17:50 <grEvenX> Jar da: I think that is very nice too, but I hope someone has experience with doing svn mirroring from other project... #freeswitch just changed to GIT and they had to spend a _lot_ of time to get it right
23:17:52 <ZaraXVI> switching to git sounds like masturbation to me
23:18:01 <LvanderRee> I don't know if I am capable, if I have enough time, and if I will be using Php for a long time anymore... But I very much do like the idea. Collaboration and ease of use for all (plugin)developers
23:18:08 <lsmith> francois: you can create an organization on github these days
23:18:27 <francois> lsmith: whoa, an organization!
23:18:33 <jwage> francois I want to help with the development for sure
23:18:35 <francois> is there name squatting on Propel ?
23:18:40 <jwage> francois: why can you not lead it?
23:19:02 <francois> jwage: well, it seems I have no choice
23:19:08 <francois> jwage: noone else will
23:19:13 <lsmith> choice if overrated :)
23:19:18 <lsmith> is
23:19:24 <francois> lsmith: good one
23:19:25 <jwage> you should want to :)
23:19:31 <Hope-Work> When I try to load a new propel object via TablePeer::fromArray($dataFromCustomSQLQuery), it adds every query to the [modifiedColumns:protected] array, increasing the size of the results *dramatically*. How do i keep this from happening?
23:19:46 <francois> ah! Hope-Work !
23:19:50 <francois> welcome
23:19:58 <francois> We were all expecting you
23:20:03 <Hope-Work> francois, huh?
23:20:11 <grEvenX> lol
23:20:12 <francois> could you all welcome Hope-Work please?
23:20:13 <IvoAz> :D
23:20:18 <Hope-Work> is francois a bot?
23:20:21 <IvoAz> welcome, Hope-Work!
23:20:22 <grEvenX> hi H
23:20:22 <grEvenX> Hi Hope-Work
23:20:23 <dvj> wb Hope-Work! missed you!
23:20:25 <grEvenX> ;)
23:20:35 <Hope-Work> !seen Hope-Work
23:20:54 <Yrwein> Welcome Hope-Work. .))
23:20:58 <lsmith> Hope-Work: you just asked the lead developer of Propel if he is a bot :P
23:21:04 <IvoAz> what is the new feature we hear on the twitter? ;)
23:21:08 <Hope-Work> bah i'm sorry
23:21:12 <b00giZm> :D
23:21:20 <Hope-Work> i'm not used to being welcomed so cordially by humans
23:21:21 <annismckenzie> I guess that was an inside joke. ;-)
23:21:39 <LvanderRee> haha great!
23:21:48 <grEvenX> I'd feel very happy with francois taking the lead, he has shown great comitment to the Propel project and great skills
23:21:53 <francois> Hope-Work: sorry, it's just funny 'coz we've been taling for an hour about the future of Propel, and you come here and ask a question about the past of Propel
23:22:05 <LvanderRee> a real user ;)
23:22:17 <francois> LvanderRee: inded
23:22:22 <b00giZm> how many people are on the core team of propel 1.x? is it just you, francois?
23:22:41 <francois> Hope-Work: try $obj->clearModifiedColumns()
23:22:44 <grEvenX> who is KrAken?
23:22:49 <LvanderRee> what is core
23:22:52 <LvanderRee> KRavEN
23:22:58 <Hope-Work> francois, i am glad it is the past. My company is stuck forever w/ a horribly ancient v of propel i can find no documentation on.
23:23:01 <francois> b00giZm: There is no core team per se
23:23:03 <grEvenX> KRaVEN even
23:23:09 <LvanderRee> KRavEN is an american, helping out especially with MSsql
23:23:38 <grEvenX> i've seen there has been some commits from him
23:23:39 <Hope-Work> francois, from one PHP pro to another, I would love an ORM that actually implemented ArrayAccess.
23:23:48 <Hope-Work> i use that in my own simplistic ORM
23:23:51 <francois> there are five people with commit access if that's what you want to know
23:23:58 <lsmith> ok ... i was already dead 30min before the meeting .. time to go into coma for me
23:24:06 <francois> Hope-Work: Use Doctrine1
23:24:33 <lsmith> good night all!
23:24:34 <francois> lsmith: thanks for your time
23:24:37 <LvanderRee> byebye
23:24:41 <grEvenX> lsmith: thanks for the your povs, good night :)
23:24:44 <Phenix> lsmith: bye
23:24:48 <Jarda> ok, well, I'm off to bed. I can send the log to you francois tomorrow
23:24:55 <Hope-Work> Call to undefined method Hierarchy::clearModifiedColumns()
23:25:00 <Hope-Work> sigh
23:25:01 <francois> Are there any more subjects we need to discuss tonight?
23:25:01 <b00giZm> so there's someone who could take the lead in the propel 1.x branch if you take the lead in 2.x
23:25:11 <IvoAz> the new feature?
23:25:18 <IvoAz> :)
23:25:20 <Jarda> IvoAz: migrations
23:25:24 <annismckenzie> Migrations!
23:25:26 <Jarda> IvoAz: follow the tickets!
23:25:37 <grEvenX> :P
23:25:41 <francois> Hope-Work: sorry, try resetModified()
23:25:51 <LvanderRee> francois when will you create the base for Propel2 on github?
23:25:56 <francois> b00giZm: not really
23:26:05 <francois> LvanderRee: not tonight
23:26:17 <LvanderRee> :D need some sleep as well ;)
23:26:33 <XpLo^bn> will propel 1.x stop providing new feature when 2.x start ?
23:26:51 <Hope-Work> francois, thank you, sir, for your help and time and the project.
23:26:56 <annismckenzie> Will 1.6 be the last?
23:27:01 <francois> XpLo^bn: My company (and others) use Propel 1.X and will keep on using it for a long time
23:27:15 <francois> XpLo^bn: that's a good insurnce that the 1.x branch will live
23:27:18 <LvanderRee> As said, I have some time tomorrow, but will not start before a base has been created on git
23:27:25 <annismckenzie> In Propel 1.x I mean.
23:27:34 <francois> although I can't guarantee the same pace in improvements/bugfixes
23:27:49 <IvoAz> migrations is great one, GJ :)
23:27:51 <francois> If any of you wants to give a hand or take the lead on Propel 1.x, tell me
23:28:01 <francois> annismckenzie: I guess so
23:28:12 <XpLo^bn> of course that would be crazy to keep the same pace with 2 branch:)
23:28:39 <LvanderRee> francois Ow and one other question, have got some time to take a look at the complex-join branch? It is compatible, but do you like it? can it be merged in 1.6
23:28:54 <francois> LvanderRee: I need to dedicate a few hours to it
23:29:05 <francois> I like it, but I still have to validate a few stuff
23:29:15 <francois> Propel 1.6 definitely needs this
23:29:19 <francois> so don't be afraid
23:29:35 <francois> (I've been kind of occupied with the migrations stuff lately)
23:29:46 <LvanderRee> francois no problem, thing is that I don' t like it to be for nothing, and me requiring to keep on patching propel for my work to be able to perform complex joins
23:30:03 <annismckenzie> Complex-join branch — care to explain a little bit, LvanderRee?
23:30:54 <b00giZm> having joins with ... JOIN t ON t.foo_id = f.id AND ... ?
23:30:54 <francois> Ok guys, time to finish the "Future of Propel2 meeting"
23:30:58 <b00giZm> ok
23:31:07 <annismckenzie> sounds good
23:31:09 <francois> It was nice talking to you all
23:31:25 <francois> don't hesitate to continue the discussion on the Propel-devs mailing-list
23:31:39 <annismckenzie> Thanks for the awesome work done in Propel 1.4 and up!
23:31:44 <francois> and watch my github acount for the Propel2 bootstrap
23:31:56 <LvanderRee> annismckenzie I am one of those who has commit rights, and created a branch to solve some issues, see ticket: http://www.propelorm.org/ticket/878
23:32:09 <francois> http://github.com/fzaninotto
23:32:13 <Phenix> francois: thank for this meeting
23:32:28 <weaverryan> very good to listen in guys - I look forward to seeing things get rolling - lot's of excellent ideas
23:32:33 <weaverryan> I feel smarter now :)
23:32:39 <annismckenzie> b00giZm: That already works with addMultipleJoin() (actually had to use it today)
23:33:09 <francois> annismckenzie: addMultipleJoin() is flawed
23:33:20 <francois> it has an SQL injection vulnerability
23:33:45 <XpLo^bn> definitly awesome work on propel francois , you re so good that no one dare take the lead :D
23:33:54 <francois> annismckenzie: that's what LvanderRee's branch is for
23:34:18 <francois> XpLo^bn: I'm really not attached to it. Do you want it?
23:34:26 <b00giZm> yeah i know, i wrote a blog posting about it... i would post the link but unfortunately, posterous screwed up their markdown-support and my blog looks like crap ;)
23:34:27 <XpLo^bn> lol no way haha
23:35:03 <XpLo^bn> i couldnt follow any of your talk about doctrine <=> propel, i dont understand anything in doctrine blog ~
23:35:06 <Yrwein> Thanks for this meeting too and Francois and others for developing propel. See ya later.
23:35:37 <francois> XpLo^bn: from an end user's point of view, Propel2 won't change much
23:35:46 <francois> The difference will be on the inside
23:35:56 <XpLo^bn> i ll keep helping ppl on forum/maling list, that s all i can do
23:36:10 <francois> XpLo^bn: please continue :)
23:36:32 <francois> ok, I'm off
23:36:42 <francois> good night/day everybody!
23:36:48 <b00giZm> see you ;) good night!
23:36:54 <XpLo^bn> night ~
23:36:58 <grEvenX> nice talking to you all
23:36:58 <Phenix> francois: bye
23:37:02 <arlo> bye
23:37:03 <LvanderRee> good night
23:37:05 <grEvenX> need to hed to bed here as well
23:37:20 <LvanderRee> I will be off too guys, see you online next time ;)
23:37:44 <grEvenX> and remember, #propel is open 24/7
23:37:45 <grEvenX> ;)
23:38:29 <b00giZm> bye ;) nice talking.