Log of #symfony-dev meeting 20110922 (all times GMT-4)

transcript.txt

Sep 22 11:01:12 <lsmith>	lets start then
Sep 22 11:01:16 <lsmith>	jmikola|w: weaverryan
Sep 22 11:01:27 <weaverryan>	here here
Sep 22 11:01:39 <lsmith>	first topic .. kbond take it away
Sep 22 11:01:40 <lsmith>	ability to set info message for configuration nodes http://bit.ly/nIuAcZ
Sep 22 11:01:46 <jmikola|w>	here
Sep 22 11:02:14 <kbond>	ok, well what are the thoughts on that PR? good, bad, ugly?
Sep 22 11:02:18 <lsmith>	kbond: just briefly explain what your PR is about, what questions there are
Sep 22 11:02:20 *	avalanche123 has quit (Quit: Computer has gone to sleep.)
Sep 22 11:02:37 <lsmith>	are there still open issues from your POV?
Sep 22 11:03:10 <lsmith>	fabpot: do you still have concerns with this PR?
Sep 22 11:03:12 <kbond>	I guess the main issue was that it was just a system to add documentation, not any sort of generator
Sep 22 11:03:49 <fabpot>	I think the main concern was that we need to use this for a generator to see if it fits our needs
Sep 22 11:04:03 <lsmith>	right so the question is more if a generator is really possible with this .. or if we have to wait until we have one
Sep 22 11:04:08 <kbond>	I have expanded this PR in another branch (https://github.com/kbond/symfony/tree/config_dump_command) which adds a rudimentary dump command
Sep 22 11:04:28 <jmikola|w>	by generator, do we mean a console command that spits out config docs?
Sep 22 11:04:35 <kbond>	soory, thats what I mean
Sep 22 11:04:35 <jmikola|w>	or something to produce rst for the online docs
Sep 22 11:04:48 <kbond>	a dump command
Sep 22 11:04:57 *	termleech (~termleech@173-10-174-161-BusName-washingtonDC.hfc.comcastbusiness.net) has joined #symfony-dev
Sep 22 11:05:19 <fabpot>	jmikola|w: whatever the output, we need to make sure that we can generate something useful easily
Sep 22 11:06:12 <kbond>	the branch linked above dumps the default config for a bundle (with documenation/examples) to yaml
Sep 22 11:06:19 <lsmith>	kbond: do you have some exampe output?
Sep 22 11:06:47 <kbond>	a good chunk of the config reference at symfony.com
Sep 22 11:07:02 <weaverryan>	yes, bond delivered the "default" YAML reference for all of the sections
Sep 22 11:07:26 <weaverryan>	it's not a perfect science, but it made sure everything was covered and was a great way to check our work
Sep 22 11:07:28 <jmikola|w>	ah, excellent - was wondering where that came from
Sep 22 11:07:55 <jmikola|w>	so the info() blocks could be YAML comments above or to the side of each option line
Sep 22 11:07:59 <weaverryan>	sometimes even if a node doesn't have a default, it's ultimately plugged into an argument in a class that *does* have a default - so there's a question of "what does it *really* default to" - but it's minor stuff like that
Sep 22 11:08:04 <lsmith>	so does this give us enough confidence that even if there might still be minor nigglies .. they are small enough to move this to core?
Sep 22 11:08:05 <fabpot>	ok, so we just need a PR for the config_dump_command branch then, right?
Sep 22 11:08:05 *	stoefln has quit (Quit: stoefln)
Sep 22 11:08:24 <kbond>	yes, but it depends on the initial PR
Sep 22 11:08:59 <lsmith>	beberlei: ping
Sep 22 11:09:01 <jmikola|w>	weaverryan: i think the best practice was to define the default value in a Configuration tree; I don't think we can accommodate DIC defaults (we'd have to execute the extension class :)
Sep 22 11:09:08 <fabpot>	kbond: ok, can you just reference your branch in the original PR?
Sep 22 11:09:35 <fabpot>	that way, I will be able to test everything and merge PR 1099
Sep 22 11:09:55 <kbond>	fabpot: want me to merge it or just reference it in a comment?
Sep 22 11:10:20 <fabpot>	kbond: just a reference to it in a comment
Sep 22 11:10:25 *	avalanche123 (~avalanche@c-67-188-222-179.hsd1.ca.comcast.net) has joined #symfony-dev
Sep 22 11:10:26 <Stof>	hi
Sep 22 11:10:29 <kbond>	ok
Sep 22 11:10:34 <weaverryan>	later, we can hopefully go on a little sprint to fill in the infos - this could be used to initially fill out the reference manual - which is still missing most things
Sep 22 11:10:37 <lsmith>	Stof: oh .. thought you couldnt make it ..
Sep 22 11:10:48 <lsmith>	i think we just covered the configuration change
Sep 22 11:11:15 *	kertz has quit (Quit: kertz)
Sep 22 11:11:15 <lsmith>	as Seldaek still needs to wrap up some work stuff .. lets skip composer briefly and see if we can get to it later
Sep 22 11:11:25 <lsmith>	How to keep the PR/ticket queue shorter http://bit.ly/mcek74
Sep 22 11:11:34 <lsmith>	i dont want to let this topic get too much out of hand
Sep 22 11:11:56 <lsmith>	what i wonder if there is anything fabpot/stof can think of to make review easier
Sep 22 11:12:01 <beberlei>	lsmith: pong
Sep 22 11:12:12 <lsmith>	aside from this .. if there is anyone motivated to work on bug triage .. bug hunts or anything
Sep 22 11:12:18 <lsmith>	feel encouraged to step up :)
Sep 22 11:12:47 <fabpot>	lsmith: I think there is not much we can do except having more people trying to create patches
Sep 22 11:13:23 <lsmith>	fabpot: k
Sep 22 11:13:28 <fabpot>	the big problem I have is the following: most PRs break tests, PRs must be targeted to the right branch (master or 2.0), most PRs should be squased and rebased regularly
Sep 22 11:13:39 <lsmith>	beberlei: just wanted to make sure you are around once we get to the registry
Sep 22 11:13:49 <fabpot>	so, I spend a lot of time, just running the tests and adding a comment to ask for a fix
Sep 22 11:14:08 <lsmith>	fabpot: ok .. so maybe we can find some more people that are trusted that can do this work for you
Sep 22 11:14:16 <beberlei>	maybe we need to automate this
Sep 22 11:14:16 <lsmith>	right now i guess its mostly Stof
Sep 22 11:14:29 <beberlei>	it should be easy to switch to PRs and run the test and comment on a PR automatically
Sep 22 11:14:45 <Stof>	well, I don't run the testsuite for all PRs currently
Sep 22 11:14:51 <lsmith>	beberlei: not sure if you want to automatically execute contributed code
Sep 22 11:15:17 <fabpot>	lsmith: right, I think this the minimum we can ask when someone contribute a PR: make sure that tests still run
Sep 22 11:15:40 <beberlei>	lsmith: well we could do it on a very restricted machine
Sep 22 11:15:43 <lsmith>	IIRC we had an instruction page for patches right?
Sep 22 11:15:59 <fabpot>	lsmith: right
Sep 22 11:16:00 <Stof>	lsmith: yes, but most people don't read it apparently
Sep 22 11:16:02 <beberlei>	problem is people dont read that stuff
Sep 22 11:16:06 <lsmith>	is it up to date .. especially in regards to picking the right branch?
Sep 22 11:16:16 <fabpot>	lsmith: I'mpretty sure it is
Sep 22 11:16:23 <lsmith>	maybe we should just ask people to put a check list into their comment
Sep 22 11:16:26 *	bshaffer|away is now known as bshaffer
Sep 22 11:16:45 <lsmith>	and if they dont submit with that checklist .. we paste the url with the instructions
Sep 22 11:17:10 <fabpot>	lsmith: but we don't want to make contributing more difficult
Sep 22 11:17:25 <jmikola|w>	some instructions on whether something qualifies as a 2.0 or 2.1 PR would be helpful :)
Sep 22 11:17:25 <lsmith>	its not going to be super long
Sep 22 11:17:36 <jmikola|w>	it would certainly help avoid recreating PR's
Sep 22 11:17:41 <stealth35>	maybe you can add the instructions link in the github Read more
Sep 22 11:17:55 <lsmith>	its mostly is this a bug fix: yes, is this a new feature: no, are the tests still passing: yes
Sep 22 11:18:04 <jmikola|w>	or we could petition github to allow the target branch on a PR to be mutable after a PR is created :)
Sep 22 11:18:12 <lsmith>	so the checklist would be just 2-4 items
Sep 22 11:18:22 <lsmith>	but proofs that they have read the instructions
Sep 22 11:18:39 <fabpot>	lsmith: sounds good to me. we can try for some time this idea and see how it works
Sep 22 11:18:50 <lsmith>	ok .. i will try to cook something up
Sep 22 11:19:03 <lsmith>	and everybody should ponder if there is anything else we can do to address the issue
Sep 22 11:19:30 <lsmith>	again if someone wants to organize some sort of bug hunt .. feel invited .. i can help organize, but too busy to lead this myself
Sep 22 11:19:34 <lsmith>	next topic then?
Sep 22 11:19:37 <Seldaek>	just one thing
Sep 22 11:19:51 <Seldaek>	fabpot: I know it's a lot of work put on you, but please try to comment when you think something is bad or missing something
Sep 22 11:20:10 <Seldaek>	because PRs with no feedback for months are really annoying from submitters POV
Sep 22 11:20:45 <Seldaek>	and since you have the final cut, discussions tend to die down waiting for your decision
Sep 22 11:20:48 <fabpot>	Seldaek: when I don't add a comment, that's because I need to think about the PR more and work on the code before I can give an opinion
Sep 22 11:21:22 <lsmith>	fabpot: well in that case you can maybe just add exactly that "initial review done, need to think more"
Sep 22 11:21:32 <fabpot>	ok, will try to do that
Sep 22 11:21:35 <lsmith>	thx
Sep 22 11:21:40 <lsmith>	Seldaek .. your on
Sep 22 11:21:41 <lsmith>	pushing composer forward http://bit.ly/qPTiQ0
Sep 22 11:21:42 <Seldaek>	yeah I don't want a final judgement, but just to know you're not ignored feels better
Sep 22 11:22:03 <beberlei>	Seldaek: its really hard to keep up with the users pace, even for doctrine it keeps me up and we have much fewer issues :)
Sep 22 11:22:32 <Seldaek>	beberlei: I realize it's not easy, I can't even keep up with the little I have to do
Sep 22 11:22:37 <Seldaek>	I'm not sure what there is to discuss about composer
Sep 22 11:22:48 <lsmith>	yeah .. we all need to do a better job of keeping tasks like finding out that a PR has failing tests away from fabpot
Sep 22 11:22:52 <jmikola|w>	perhaps github tags could be used there (to denote in-progress PR's, delays or "still thinking")
Sep 22 11:22:53 <beberlei>	whats the state of composer?
Sep 22 11:22:55 <weaverryan>	can you explain the status? What are the next steps? What can people do to get involved?
Sep 22 11:23:15 <Seldaek>	everzet_ spent quite some time on a refactoring that is still in progress, cleaning up things that we've built up, which is good
Sep 22 11:23:15 <naderman>	hey
Sep 22 11:23:26 <Stof>	jmikola|w: tags suck for PRs as they are not shown on the Pr page
Sep 22 11:24:07 <Seldaek>	other than that, it's coming along nicely I think, but things are still pretty slow
Sep 22 11:24:16 <lsmith>	Seldaek: when do you expect things to stabelize?
Sep 22 11:24:19 <Seldaek>	we do have #composer-dev though, if anyone feels like helping
Sep 22 11:24:24 <lsmith>	going at the current rate
Sep 22 11:24:25 <weaverryan>	Seldaek: what work still needs to be done before, for example, I could start moving some things out of my deps and into a composer file? Or are we there already?
Sep 22 11:24:40 *	dbu (~david@158-26.79-83.cust.bluewin.ch) has joined #symfony-dev
Sep 22 11:24:46 <Seldaek>	weaverryan: igorw managed to install silex & deps with composer, so it's almost there
Sep 22 11:24:57 <weaverryan>	should we be encouraging composer files in bundles already?
Sep 22 11:25:19 <naderman>	it works decently when it works, when there are problems the error reporting is still pretty much non-existant which makes using it annoying
Sep 22 11:25:19 <lsmith>	ok .. so end of october should be a realistic date to be able to start testing this at a bigger scale?
Sep 22 11:25:20 <Seldaek>	right now we need to finish that big refactoring, and then send PRs to add composer.json in Sf2 components (don't do this, we have them already)
Sep 22 11:25:32 <Stof>	Seldaek: does composer support installing a bundle in the good folder for its namespace ?
Sep 22 11:25:34 <Seldaek>	lsmith: I'd hope so yes
Sep 22 11:25:46 <everzet_>	lsmith: yes
Sep 22 11:25:53 <everzet_>	:-)
Sep 22 11:26:00 <Seldaek>	Stof: not yet, once we get symfony to install we should start working on a composerbundle that integrates a Sf2-specific installer for bundles
Sep 22 11:26:08 <Stof>	IIRC, it installs it in a folder named after the package name, which is wrong for bundles
Sep 22 11:26:13 <lsmith>	ok .. i think making that date is important .. as we want to get 2.1 LTS out this year
Sep 22 11:26:20 <Gregwar>	Seldaek, including adding it to the app kernel and autoloader ?
Sep 22 11:26:32 <Seldaek>	Gregwar: sure it could be a part of the installer I suppose
Sep 22 11:26:46 <jmikola|w>	Stof: that was going to be my next question
Sep 22 11:26:50 <Seldaek>	also another thing we could quickly discuss now, is that we need a custom package type for bundles.. that is sf2 specific
Sep 22 11:26:56 <jmikola|w>	afaik, it drops submodules into vendor/
Sep 22 11:27:10 <Seldaek>	we just need to set on something, and then we can ask people to add composer.json files in their bundle repos
Sep 22 11:27:11 <beberlei>	what is a package type
Sep 22 11:27:20 <jmikola|w>	Gregwar: perhaps the AppKernel and autoloader should be through a ComposerBundle?
Sep 22 11:27:21 <fabpot>	last time I tried to use composer, it installed the same package each time I ran composer install
Sep 22 11:27:23 <naderman>	beberlei: it is used for filtering and custom installer
Sep 22 11:27:25 <everzet_>	jmikola|w: it's because for now we have only 1 installer - for library type packages
Sep 22 11:27:31 <Seldaek>	basically it's just used to figure out which installer can install the package
Sep 22 11:27:39 <Gregwar>	jmikola|w, yes, there is already code in the symfony's generator to do that, maybe this could be reused
Sep 22 11:27:41 <naderman>	fabpot: yes, the list of installed packages wasn't maintained
Sep 22 11:27:41 <lsmith>	Seldaek: i assume there is nothing in the way of documentation yet?
Sep 22 11:27:43 <beberlei>	ah k
Sep 22 11:27:58 <Seldaek>	lsmith: just the few bits I wrote on http://packagist.org/about and /about-composer
Sep 22 11:28:00 <fabpot>	naderman: ok, and is it fixed now?
Sep 22 11:28:10 <everzet_>	fabpot: in progress ;-)
Sep 22 11:28:10 <Seldaek>	fabpot: partly fixed by the refactoring, not finalized
Sep 22 11:28:17 <fabpot>	ok, great
Sep 22 11:28:29 <Seldaek>	so anyway, we need something like "Symfony2-Bundle" or whatever as a package type
Sep 22 11:28:35 <Seldaek>	that every bundle uses
Sep 22 11:28:38 <everzet_>	Seldaek: exactly
Sep 22 11:28:41 <Gregwar>	I thought having really simple command line for installing third party bundles could really empower Symfony
Sep 22 11:28:59 <Seldaek>	Gregwar: it's coming:)
Sep 22 11:29:05 <Seldaek>	(feel free to help)
Sep 22 11:29:30 <Seldaek>	so, is Symfony2-Bundle ok for everyone or do we feel like bikeshedding this?
Sep 22 11:29:36 <Gregwar>	Seldaek, I would I i had more free time :/
Sep 22 11:29:40 *	AlHornair (~alain@160.85.6.73) has joined #symfony-dev
Sep 22 11:29:43 <lsmith>	Seldaek: we can bike shed later :)
Sep 22 11:29:46 <Seldaek>	no
Sep 22 11:29:54 <naderman>	Seldaek: it's ok, just go with that
Sep 22 11:29:55 <Seldaek>	this needs to be decided before people add composer.json files
Sep 22 11:29:58 <everzet_>	Seldaek: Symfony2-Bundle for what?
Sep 22 11:30:03 <naderman>	everzet_: package type
Sep 22 11:30:08 <everzet_>	oh
Sep 22 11:30:15 <everzet_>	:-)
Sep 22 11:30:21 <everzet_>	yeah
Sep 22 11:30:55 <everzet_>	but what about sf2bundle ?
Sep 22 11:31:07 *	avalanche123 has quit (Quit: Computer has gone to sleep.)
Sep 22 11:31:08 <naderman>	unnecessary abbreviation
Sep 22 11:31:10 <everzet_>	less words - less places for mistake
Sep 22 11:31:14 <Seldaek>	well, it is a global type
Sep 22 11:31:22 <Seldaek>	so it should be namespaced kind of
Sep 22 11:31:25 <Seldaek>	and not some shorthand
Sep 22 11:31:39 <lsmith>	ok .. i dont think its feasible to discuss this in this meeting .. we can figure this out seperate .. via IRC or mailinglist
Sep 22 11:31:40 <everzet_>	then SymfonyBundle
Sep 22 11:31:46 <naderman>	lsmith: exactly
Sep 22 11:31:53 <Seldaek>	alright
Sep 22 11:31:55 <everzet_>	lsmith: agree
Sep 22 11:31:59 <Seldaek>	I just meant it should happen soon
Sep 22 11:32:05 <naderman>	Seldaek: write an email to list
Sep 22 11:32:10 <lsmith>	then i would like to move to the next topic
Sep 22 11:32:12 <Seldaek>	naderman: you :p
Sep 22 11:32:31 <lsmith>	ACL and proxies: http://bit.ly/p6cOvd
Sep 22 11:32:39 <jalliot>	I can discuss that
Sep 22 11:32:59 *	AlHornair has quit (Client Quit)
Sep 22 11:32:59 <lsmith>	jalliot: go ahead
Sep 22 11:33:09 <jalliot>	to be brief, at the moment, ACL do not work with Doctrine proxies (be it ORM, ODM, etc.)
Sep 22 11:33:12 <lsmith>	johannes_: ping
Sep 22 11:33:24 *	stealth35 (~irc@abo-60-32-69.lil.modulonet.fr) has left #symfony-dev
Sep 22 11:33:39 <jmikola|w>	jalliot: is ACL still a direct PDO interface?
Sep 22 11:33:41 <Gregwar>	jalliot, that's caused by the way the ObjectIdentify works, it is'nt ?
Sep 22 11:33:42 <jalliot>	and forces us to fetch the entities/documents even though we could use the unit of work to get the identifiers
Sep 22 11:33:56 <jalliot>	it uses DBAL
Sep 22 11:34:03 <jmikola|w>	ah, right - that's what I was thinking of
Sep 22 11:34:07 <fabpot>	IIRC, ACL are tightly coupled with Doctrine, right?
Sep 22 11:34:08 <jalliot>	and yes it's because of ObjectIdentity
Sep 22 11:34:18 <jalliot>	only with DBAL
Sep 22 11:34:20 <Seldaek>	fabpot: yeah, which is another problem :)
Sep 22 11:34:29 <jalliot>	it sure is
Sep 22 11:34:50 <jalliot>	so my PR adds a new service with a new DIC tag for bundles to register a new "identity resolver"
Sep 22 11:34:51 <fabpot>	so, my first reaction is: why not move the whole thing to the Doctrine bundle (I know it does not fix anything), but at least, it makes it clear that without Doxtrine, it cannot work
Sep 22 11:35:04 <fabpot>	or the Doctrine bridge
Sep 22 11:35:44 <jalliot>	it might be best for 2.1 to decouple it from Doctrine altogether
Sep 22 11:35:46 *	vranac has quit (Quit: Leaving.)
Sep 22 11:35:47 <Stof>	fabpot: it does not solve the issue pointed by jalliot: ACL is broken for entities as it creates a different ACE for the proxy object than the original object
Sep 22 11:36:03 <fabpot>	Stof: I understand that
Sep 22 11:36:07 <Gregwar>	Just for info, the current behaviour is: http://bit.ly/oJFKPR
Sep 22 11:36:08 <Stof>	and opensky guys worked on a mongo provider for the ACL IIRC
Sep 22 11:36:30 <lsmith>	Stof: think it was someone else .. iampersitant maybe
Sep 22 11:36:32 <jmikola|w>	Stof: recently? I wasn't aware we were using ACL for anything
Sep 22 11:36:35 <jalliot>	Stof: right, atm if we want to use it for doctrine entities/documents we have to make sure we never use proxies OR write a custom ObjectRetrievalStrategy
Sep 22 11:37:40 <Stof>	jmikola|w: no, long ago there was a PR for a mongo storage which wasn't merged as fabpot did not wanted to add something linked to Mongo in the components
Sep 22 11:37:41 <jalliot>	I pinged johannes_ by mail already and he said my implementation does not cover all cases but never said what exactly...
Sep 22 11:37:44 <Stof>	lsmith: ah maybe
Sep 22 11:38:33 <jalliot>	The PR's clearly nor perfect: tests are missing and the names must be changed to something shorter
Sep 22 11:39:09 <jalliot>	but in the meantime this is the only way to get it fully working with Doctrine or any other library which uses proxies
Sep 22 11:39:13 <lsmith>	jalliot: but the main point is that you add a service that is more efficient and reliable in finding out the id to use in the ACL
Sep 22 11:39:29 <jalliot>	not the ID, the "type" (which is the class name)
Sep 22 11:39:34 <lsmith>	k
Sep 22 11:39:44 <lsmith>	but it would be optional
Sep 22 11:39:51 <jalliot>	the id is found by getId() already
Sep 22 11:39:55 <Stof>	lsmith: for the id, this is already handled by the interface
Sep 22 11:40:14 <lsmith>	sounds like a sensible and BC concept to me
Sep 22 11:40:15 <jalliot>	only problem is that it automatically loads the entity if it is a proxy, even though we don't need it
Sep 22 11:40:33 <lsmith>	beberlei: can you chime in there?
Sep 22 11:40:55 *	stealth35 (~irc@abo-60-32-69.lil.modulonet.fr) has joined #symfony-dev
Sep 22 11:41:08 <beberlei>	even though acl is coupled to doctrine backend (dbal based) it has nothing to do with entities
Sep 22 11:41:35 <jalliot>	beberlei: right, this is not the issue
Sep 22 11:41:50 <Stof>	beberlei: the current issue is that an entity defines 2 domain objects for the ACL currently because get_class returns a different result when you get a proxy
Sep 22 11:41:50 <beberlei>	well johannes suggested that we standardize on a proxy class generation pattern
Sep 22 11:42:12 <beberlei>	i.e. ProxyNamespace\$original__CG__<library_forexample_DoctrineProxy>
Sep 22 11:42:26 <beberlei>	i think this is a good way to solve the detection generically
Sep 22 11:42:34 <beberlei>	but its open until doctrine 2.2
Sep 22 11:42:40 <jalliot>	beberlei: yes it would
Sep 22 11:42:41 <Stof>	this will not change the fact that get_class() is different.
Sep 22 11:42:54 <jalliot>	but ACL would remain broken in Symfony 2.0 then
Sep 22 11:42:56 <fabpot>	beberlei: that's just a hack, no?
Sep 22 11:42:57 <lsmith>	beberlei: 2.2 is planned for when .. december?
Sep 22 11:42:58 <Stof>	it will only make it easier (and more efficient) to find the original class
Sep 22 11:43:15 <jalliot>	and it doesn't solve the lazy-loading issue
Sep 22 11:43:22 <beberlei>	fabpot: yes essentially, the other solution would be to always go to the super class
Sep 22 11:43:33 <jalliot>	my solution would work with everything, not specifically doctrine
Sep 22 11:43:44 <beberlei>	but with mapped superclasses this will lead to strange results aswell
Sep 22 11:43:47 <fabpot>	I'm -1 on this hack as it does not solve the problem in a generic way
Sep 22 11:44:00 <jalliot>	you would only add to create a new identity resolver for your custom new great library which works with proxies or lazy loading entities or somtehing
Sep 22 11:44:21 <jalliot>	fabpot Are you talking about my PR or johannes_ proposal?
Sep 22 11:44:35 <fabpot>	jalliot: johannes_ proposal
Sep 22 11:44:37 <beberlei>	jalliot: how would your solution work?
Sep 22 11:45:06 *	robo47 has quit (Quit: Leaving)
Sep 22 11:45:08 <jalliot>	Every time we need to retrieve an object identity we loop over the identity resolvers registered through the DIC
Sep 22 11:45:28 <jalliot>	the first to return a non-null object identity wins, otherwise, the current implementation is used
Sep 22 11:45:33 <beberlei>	and that fiddles with the $classname retrieved from get_class?
Sep 22 11:45:56 <Stof>	beberlei: yes, as get_class is only used if none of the resolvers supported the class
Sep 22 11:45:59 <jalliot>	for Doctrine ORM, we check if a EntityManager is registered for this object and if it is we check for proxy class and stuff
Sep 22 11:46:10 *	stealth35 (~irc@abo-60-32-69.lil.modulonet.fr) has left #symfony-dev
Sep 22 11:46:25 <beberlei>	thats a nice solution actually, i rather take that over the __CG__ hack aswell :)
Sep 22 11:46:26 *	stealth35 (~irc@abo-60-32-69.lil.modulonet.fr) has joined #symfony-dev
Sep 22 11:46:36 *	termleech_work (~termleech@173-10-174-161-BusName-washingtonDC.hfc.comcastbusiness.net) has joined #symfony-dev
Sep 22 11:46:45 *	termleech has quit (Disconnected by services)
Sep 22 11:46:49 *	termleech_work is now known as termleech
Sep 22 11:46:54 <jalliot>	beberlei: Good to hear :) I still need to find some better names and to add some tests
Sep 22 11:46:56 <Gregwar>	What's wrong with the jalliot's PR (that adds an object identity service) ?
Sep 22 11:47:07 *	stealth35 (~irc@abo-60-32-69.lil.modulonet.fr) has left #symfony-dev
Sep 22 11:47:13 <jalliot>	but I'd really like to have johannes_ opinion since he said it doesn't cover all cases
Sep 22 11:47:18 <lsmith>	ok .. so we will continue to persue jalliot's approach
Sep 22 11:47:24 *	stealth35 (~irc@abo-60-32-69.lil.modulonet.fr) has joined #symfony-dev
Sep 22 11:47:30 <lsmith>	jalliot: i havent seen johannes_ on IRC as much the last days
Sep 22 11:47:36 <lsmith>	but he was definately active committing
Sep 22 11:47:44 <lsmith>	if you can try to grab him in here
Sep 22 11:47:55 <lsmith>	i will poke him about this when i see he is online
Sep 22 11:48:16 <jalliot>	lsmith: I'll send him an email then :)
Sep 22 11:48:23 <lsmith>	moving to the last topic then
Sep 22 11:48:24 <lsmith>	Registry implementation for Document Managers: http://bit.ly/oL5rdC
Sep 22 11:48:33 <lsmith>	beberlei: does that look good to you?
Sep 22 11:48:40 *	sblack (~sblack@c-67-180-89-162.hsd1.ca.comcast.net) has joined #symfony-dev
Sep 22 11:49:00 <lsmith>	err .. i meant my PR that i link there
Sep 22 11:49:01 <lsmith>	one sec
Sep 22 11:49:20 <lsmith>	https://github.com/symfony-cmf/symfony-cmf/pull/108/files#diff-1
Sep 22 11:49:27 <lsmith>	this file would be added to the Doctrine Bridge
Sep 22 11:49:36 *	stealth35 (~irc@abo-60-32-69.lil.modulonet.fr) has left #symfony-dev
Sep 22 11:49:42 <lsmith>	these two files would be added to doctrine common
Sep 22 11:49:43 <lsmith>	https://github.com/symfony-cmf/symfony-cmf/pull/108/files#diff-4
Sep 22 11:49:48 *	Court (~Court@c-174-54-219-117.hsd1.pa.comcast.net) has joined #symfony-dev
Sep 22 11:49:48 <lsmith>	https://github.com/symfony-cmf/symfony-cmf/pull/108/files#diff-5
Sep 22 11:49:53 <lsmith>	file names are not yet ideal
Sep 22 11:49:58 <beberlei>	well i did a much more generic registry than the ORM one in the couchdb bundle . This would help very much to implement a single UniqueConstraint validator and other stuff based on "object managers" in general
Sep 22 11:50:15 <beberlei>	and your implementation looks good aswell
Sep 22 11:50:21 <lsmith>	beberlei: my PR is based on the one from couchdb
Sep 22 11:50:34 <beberlei>	we should implement that to be able to get rid of tons of LOC in MongoDB, ORM and couchdb bundles, aswell as PHPCR
Sep 22 11:50:40 <lsmith>	i just added some more abstract methods, moved the container stuff out
Sep 22 11:50:46 <beberlei>	and i will move an interface of that kind into Doctrine Common
Sep 22 11:51:20 <lsmith>	beberlei: ok .. so we have a general agreement? then we can work on the necessary PR's and settle this topic
Sep 22 11:51:21 *	krymen (~krymen@87.99.38.40) has joined #symfony-dev
Sep 22 11:51:24 *	stealth35 (~irc@abo-60-32-69.lil.modulonet.fr) has joined #symfony-dev
Sep 22 11:51:50 <lsmith>	as i said the main thing i see left is tweak the naming of things
Sep 22 11:51:57 <beberlei>	question is how to handle the ORM code that exists already
Sep 22 11:52:10 <Stof>	beberlei: using the code of lsmith's PHPCR implementation, you can even move the abstract class to Common and the ContainerAware implementation can be put in Bridge and used by all Doctrine*Bundle by simply creating a new instance
Sep 22 11:52:14 <beberlei>	the EMF should probably be a proxy for the OMF
Sep 22 11:52:15 <lsmith>	beberlei: we will have to maintain BC there
Sep 22 11:52:42 <lsmith>	Stof: that was the plan .. but for the ORM we will have to maintain a BC option
Sep 22 11:53:06 <lsmith>	which will essentially be a stupid proxy class that redirects the method calls
Sep 22 11:53:12 <Stof>	beberlei: making the current interface extend the Common one (for the typehinting) and supporting both method names in the registry (with an extended version of the general one)
Sep 22 11:53:44 <Stof>	and current methods should be marked as deprecated to encourage users to use the generic method names
Sep 22 11:53:52 <Stof>	fabpot: what do you think about it ?
Sep 22 11:54:35 <fabpot>	Stof: I must admit that I don't had any strong opinion on the topic. The only thing is that it must be part of Doctrine and not Symfony.
Sep 22 11:55:04 <lsmith>	fabpot: yes .. only the bare minimum of code to make it container aware will be in the doctrine bridge
Sep 22 11:55:11 <lsmith>	everything else will be in doctrine common
Sep 22 11:55:19 <fabpot>	lsmith: yes
Sep 22 11:55:33 <lsmith>	we just have to maintain BC with the current ORM one .. which uses getEntityManager() as method names
Sep 22 11:55:34 <fabpot>	then, it's fine for me
Sep 22 11:55:38 <beberlei>	we can get rid of tons of code in mongodb and couchdb then aswell, so that would help keep those bundles up to speed with ORM
Sep 22 11:55:39 <lsmith>	which the generic one will not
Sep 22 11:56:03 <beberlei>	i can definately work on that more, i havent had time lately for much OSS but it will get better soon
Sep 22 11:56:12 <fabpot>	lsmith: we will need to create an adapter to maintain BC, but that should not be too difficult
Sep 22 11:56:16 *	stealth35 (~irc@abo-60-32-69.lil.modulonet.fr) has left #symfony-dev
Sep 22 11:56:19 <lsmith>	fabpot: yeah
Sep 22 11:56:22 <Stof>	but it means that Common 2.2 will become the requirement for 2.1 as we will need the code
Sep 22 11:56:26 *	stealth35 (~irc@abo-60-32-69.lil.modulonet.fr) has joined #symfony-dev
Sep 22 11:56:40 <Stof>	and so we will have to wait until the Doctrine release before releasing Symfony
Sep 22 11:56:45 <lsmith>	oh right .. beberlei whats the release schedule there?
Sep 22 11:57:00 <beberlei>	Stof: 2.2 common can be released earlier, but DBAL and ORM are due in december anyways
Sep 22 11:57:21 <lsmith>	k
Sep 22 11:57:43 <lsmith>	sounds good then
Sep 22 11:57:50 <lsmith>	and with that .. meeting over i guess
Sep 22 11:57:54 <Stof>	lsmith: can you send your current implementation to Doctrine for the part going to Common ?
Sep 22 11:57:54 <lsmith>	thx all
Sep 22 11:57:58 <lsmith>	next meeting will be in 2 weeks