Today I tried upgrading to Propel 1.5.2, which broke my code. This is the second "." release on the 1.5 branch that was totally unusable for me, the first one had issues with large schemas that couldn't be generated without splitting them in chunks. This new release actually broke method signatures on foreign key fields (Ticket: http://www.propelorm.org/ticket/1019).
Please know that I think the development of Propel and it's features are great, and I don't write this e-mail to say that I'm mad at the propel devs or anything the like for framework breaking, but I think this is a result of too big changes in the framework without enough testing. What I'd like was some discussion on how these situations could be avoided in the future. People come to expect that a "." release is pretty much a stable version of a software.
My proposal is to do release-candidates even for "." releases so large-scale users of the propel library can do some testing before the code is actually released as a "." release. What's your guys' thoughts on the topic?
> Today I tried upgrading to Propel 1.5.2, which broke my code. > This is the second "." release on the 1.5 branch that was totally unusable for me, > the first one had issues with large schemas that couldn't be generated without splitting them in chunks. > This new release actually broke method signatures on foreign key fields (Ticket: http://www.propelorm.org/ticket/1019).
> Please know that I think the development of Propel and it's features are great, and I don't write this e-mail to say > that I'm mad at the propel devs or anything the like for framework breaking, > but I think this is a result of too big changes in the framework without enough testing. > What I'd like was some discussion on how these situations could be avoided in the future. > People come to expect that a "." release is pretty much a stable version of a software.
> My proposal is to do release-candidates even for "." releases so large-scale users of the propel > library can do some testing before the code is actually released as a "." release. > What's your guys' thoughts on the topic?
> Best regards, > Even André Fiskvik
I totally agree.
I know Francois has already argumented why he adds new features to 1.5 branch instead of branching a 1.6.
Still I think (in z.y.z) z+1 should be just a bugfix release! It shouldn't add any configuration options and it most of all should not change ANY behaviour of a configuration option.
What I mean, is that now every foreign reference did change it's name, (introduced afaik in [1775] http://www.propelorm.org/changeset/1775). These kind of things SHOULD NOT HAPPEN when upgrading a z+1 release. People expect z+1 to be maintenance that fix critical bugs and security issues, not change behaviour!
Still, keep up the good work, progress isn't bad, when it's controlled.
I already answered to your ticket, and it seems that your issue is more with the 1.5 branch than with the 1.5.2 release. Your issue also has an easy fix, so I hope this won't prevent you from taking advantage of 1.5.2.
As for the release method, I run all the test suite before every commit. That means that all the tests that used to pass with the 1.5.1 still pass with 1.5.2, plus those that were added to cover the new features. The tests suite (obviously) doesn't cover all cases, but it has already tripled in size in the past six months, so rest assured that backwards compatibility is one of our core concerns.
As for offering a RC for minor releases, I simply can't afford it. Releasing a new version takes a couple hours (to document the changelog, build and upload the packages, tell the world about it), and since we use a monthly periodicity and I don't have that much time to give to Propel, I'd rather write tests and code than build RCs.
My advice would be, if you're not comfortable, to wait a bit before upgrading to a minor release.
> Today I tried upgrading to Propel 1.5.2, which broke my code. > This is the second "." release on the 1.5 branch that was totally unusable > for me, > the first one had issues with large schemas that couldn't be generated > without splitting them in chunks. > This new release actually broke method signatures on foreign key fields > (Ticket: http://www.propelorm.org/ticket/1019).
> Please know that I think the development of Propel and it's features are > great, and I don't write this e-mail to say > that I'm mad at the propel devs or anything the like for framework > breaking, > but I think this is a result of too big changes in the framework without > enough testing. > What I'd like was some discussion on how these situations could be avoided > in the future. > People come to expect that a "." release is pretty much a stable version of > a software.
> My proposal is to do release-candidates even for "." releases so > large-scale users of the propel > library can do some testing before the code is actually released as a "." > release. > What's your guys' thoughts on the topic?
> Best regards, > Even André Fiskvik
> -- > You received this message because you are subscribed to the Google > Groups "Propel Development" group. > To post to this group, send email to propel-development@googlegroups.com > To unsubscribe from this group, send email to > propel-development+unsubscribe@googlegroups.com<propel-development%2Bunsubs cribe@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/propel-development
This is completely untrue. The only relation names that changed are those of symmetrical relations, that used to break ModelQueries in Propel 1.5 ( http://www.propelorm.org/ticket/968).
These symmetrical relations are an uncommon (and, if you want my opinion, bad) way to design a model, yet Propel decided to support them fully in 1.5.2, because they were supported in 1.4.
So the problem is that something that used to work seamlessly in 1.4 didn't work the same in 1.5.0. And 1.5.0 had all the beta/RC/whatever release cycle you want, yet this problem was only discovered a after the stable release.
Now, if someone wants to help with writing more unit tests to make Propel even more robust, I'd be the first to applause.
> This is completely untrue. The only relation names that changed are > those of symmetrical relations, that used to break ModelQueries in > Propel 1.5 (http://www.propelorm.org/ticket/968).
> These symmetrical relations are an uncommon (and, if you want my > opinion, bad) way to design a model, yet Propel decided to support > them fully in 1.5.2, because they were supported in 1.4.
> So the problem is that something that used to work seamlessly in 1.4 > didn't work the same in 1.5.0. And 1.5.0 had all the beta/RC/whatever > release cycle you want, yet this problem was only discovered a after > the stable release.
Ok, I stand corrected.
Byt I can still prove my point. I started a project with 1.5.0b1 (or it might have been 1.5 HEAD before the official releases). It has a schema like the following:
This generated from the early 1.5 versions to 1.5.1 foreign references like Item::getItemReferencedByParentItemId() or something similar (and the same goes for the query classes).
Now when I upgraded to 1.5.2 90% of my queries got broken because the foreign reference changed it's name! And this was between a maintenance release!
Even if this was a bugfix and needed for 1.4 BC it did change the behaviour of generator between a maintenance release. People just don't expect things like this to happen when upgrading a maintenance release.
> Now, if someone wants to help with writing more unit tests to make > Propel even more robust, I'd be the first to applause.
> Fran�ois
Please don't get me wrong. I appreciate the great work you've done for Propel. I just hope Propel isn't going to be too much a one man project where changes aren't discussed at all (IRC is a great place..) and all the community effort is just done by opening tickets for you to fix.
I cannot completely agree with the message above (again also not to
provoke anyone). The only thing I am aware of (and could find back)
regarding broken backwards compatibility was from 1.4.x to 1.5.0+ is
the relatedBy naming as already mentioned in the release notes. See
http://www.propelorm.org/ticket/897 and http://www.propelorm.org/changeset/1651 So are you absolutely sure you have rebuild your model after you where
using Propel 1.5.0+, as from 1.5-stable the relatedBy was already
changed/corrected and nothing else should have been changed since then
(I cannot see any evidence for that in svn either).
Regarding the community-nature of Propel. I already tried many times,
very hard, to get some feedback regarding several issues, but usually
only François is the one who is responding to my messages. I tried
irc, trac and this mailinglist but all without any feedback....
Currently I am working on improving the functionality for defining
joins:
http://www.propelorm.org/ticket/878#comment:10 http://groups.google.com/group/propel-development/browse_thread/threa... I mentioned it on irc as well, but no feedback what so ever...
So if we don't want it to become a one man show, I wonder what else I
have to do to get some community feedback...
Regards
Leon
On 21 jun, 07:53, Niklas Närhinen <nik...@narhinen.net> wrote:
> > This is completely untrue. The only relation names that changed are
> > those of symmetrical relations, that used to break ModelQueries in
> > Propel 1.5 (http://www.propelorm.org/ticket/968).
> > These symmetrical relations are an uncommon (and, if you want my
> > opinion, bad) way to design a model, yet Propel decided to support
> > them fully in 1.5.2, because they were supported in 1.4.
> > So the problem is that something that used to work seamlessly in 1.4
> > didn't work the same in 1.5.0. And 1.5.0 had all the beta/RC/whatever
> > release cycle you want, yet this problem was only discovered a after
> > the stable release.
> Ok, I stand corrected.
> Byt I can still prove my point. I started a project with 1.5.0b1 (or it
> might have been 1.5 HEAD before the official releases). It has a schema
> like the following:
> This generated from the early 1.5 versions to 1.5.1 foreign references
> like Item::getItemReferencedByParentItemId() or something similar (and
> the same goes for the query classes).
> Now when I upgraded to 1.5.2 90% of my queries got broken because the
> foreign reference changed it's name! And this was between a maintenance
> release!
> Even if this was a bugfix and needed for 1.4 BC it did change the
> behaviour of generator between a maintenance release. People just don't
> expect things like this to happen when upgrading a maintenance release.
> > Now, if someone wants to help with writing more unit tests to make
> > Propel even more robust, I'd be the first to applause.
> > Fran�ois
> Please don't get me wrong. I appreciate the great work you've done for
> Propel. I just hope Propel isn't going to be too much a one man project
> where changes aren't discussed at all (IRC is a great place..) and all
> the community effort is just done by opening tickets for you to fix.
I fully agree with Leon: if Propel would be a one-man project, this is not because of anything François has done. On the contrary: if François wasn't doing what he is doing, Propel would be what is was a few months ago: a zero-man project.
I sometimes wonder whether Propel is too complicated to work as a collaborative project. Creating these intuitive interfaces is hard work, which is not easily discussed if you only have text (and English is not your native language, as is the case for many of us). Sometimes sitting around a physical notebook and a lot of hand-waving is what you need to describe these bigger ideas. On the other hand, many other projects are able to pull this off (the Linux kernel, to name one at the far edge of the "complicated" scale), so why not Propel?
If the community is not involved enough, it's because we, the individuals who make up the community, do not show enough effort. I did this for a while, following the Propel timeline RSS feed, and commenting on things that I did not understand, which lead to some improvements. At the time François gave me SVN access (with the pun subject "Would you like to commit yourself?"), I dropped out. Maybe because I got stage fright, maybe because I got a little behind on the timeline and never caught up, which made me get out of touch with the daily development, which increased the fear that I would do something that would not fit in with the rest (is this an argument for a distributed VCS?).
But today I say "to hell with my fears!" I will join Leon on his quest to expand the use of Criteria in joins (and from-clauses?), by acting as his sparring partner and commenting on his ideas. Partly because it is a large but separate chunk of work, partly because we can discuss the harder stuff in Dutch, and partly because his work for the government interests me (maybe we can do similar things in Belgium - multiple times, with all the governments we have!).
So Leon, you can expect a mail from me soon. And François, I hope this is the answer you needed to your mail: yes, I will commit myself. In fact, I think I just did.
Greetings,
Jan Fabry
PS: Niklas, I once created a web-based "Propel generator" that created the schema files and PHP classes from a database schema (because my colleagues feared the XML schema). It should not be too hard to adapt this to create a "Propel comparison tool", where you can load a schema and let different Propel versions generate the PHP files, so they can be compared. This could solve the confusion around your problem, and prevent it from happening again. Is there anyone who wants to contribute to Propel by creating this?
> Regarding the community-nature of Propel. I already tried many times, > very hard, to get some feedback regarding several issues, but usually > only François is the one who is responding to my messages. I tried > irc, trac and this mailinglist but all without any feedback.... > Currently I am working on improving the functionality for defining > joins: > http://www.propelorm.org/ticket/878#comment:10 > http://groups.google.com/group/propel-development/browse_thread/threa... > I mentioned it on irc as well, but no feedback what so ever...
> So if we don't want it to become a one man show, I wonder what else I > have to do to get some community feedback...
> Regards > Leon
>> Please don't get me wrong. I appreciate the great work you've done for >> Propel. I just hope Propel isn't going to be too much a one man project >> where changes aren't discussed at all (IRC is a great place..) and all >> the community effort is just done by opening tickets for you to fix.
> I fully agree with Leon: if Propel would be a one-man project, this is not > because of anything François has done. On the contrary: if François wasn't > doing what he is doing, Propel would be what is was a few months ago: a > zero-man project.
> I sometimes wonder whether Propel is too complicated to work as a > collaborative project. Creating these intuitive interfaces is hard work, > which is not easily discussed if you only have text (and English is not your > native language, as is the case for many of us). Sometimes sitting around a > physical notebook and a lot of hand-waving is what you need to describe > these bigger ideas. On the other hand, many other projects are able to pull > this off (the Linux kernel, to name one at the far edge of the "complicated" > scale), so why not Propel?
> If the community is not involved enough, it's because we, the individuals > who make up the community, do not show enough effort. I did this for a > while, following the Propel timeline RSS feed, and commenting on things that > I did not understand, which lead to some improvements. At the time François > gave me SVN access (with the pun subject "Would you like to commit > yourself?"), I dropped out. Maybe because I got stage fright, maybe because > I got a little behind on the timeline and never caught up, which made me get > out of touch with the daily development, which increased the fear that I > would do something that would not fit in with the rest (is this an argument > for a distributed VCS?).
> But today I say "to hell with my fears!" I will join Leon on his quest to > expand the use of Criteria in joins (and from-clauses?), by acting as his > sparring partner and commenting on his ideas. Partly because it is a large > but separate chunk of work, partly because we can discuss the harder stuff > in Dutch, and partly because his work for the government interests me (maybe > we can do similar things in Belgium - multiple times, with all the > governments we have!).
> So Leon, you can expect a mail from me soon. And François, I hope this is > the answer you needed to your mail: yes, I will commit myself. In fact, I > think I just did.
Thank you for your contribution !
François work is very good, keep up the good work.
> PS: Niklas, I once created a web-based "Propel generator" that created the > schema files and PHP classes from a database schema (because my colleagues > feared the XML schema). It should not be too hard to adapt this to create a > "Propel comparison tool", where you can load a schema and let different > Propel versions generate the PHP files, so they can be compared. This could > solve the confusion around your problem, and prevent it from happening > again. Is there anyone who wants to contribute to Propel by creating this?
> On 21 Jun 2010, at 09:53, LvanderRee wrote:
> > Hello Niklas/all,
> > Regarding the community-nature of Propel. I already tried many times, > > very hard, to get some feedback regarding several issues, but usually > > only François is the one who is responding to my messages. I tried > > irc, trac and this mailinglist but all without any feedback.... > > Currently I am working on improving the functionality for defining > > joins: > > http://www.propelorm.org/ticket/878#comment:10
> > So if we don't want it to become a one man show, I wonder what else I > > have to do to get some community feedback...
> > Regards > > Leon
> >> Please don't get me wrong. I appreciate the great work you've done for > >> Propel. I just hope Propel isn't going to be too much a one man project > >> where changes aren't discussed at all (IRC is a great place..) and all > >> the community effort is just done by opening tickets for you to fix.
> >> Niklas
> -- > You received this message because you are subscribed to the Google > Groups "Propel Development" group. > To post to this group, send email to propel-development@googlegroups.com > To unsubscribe from this group, send email to > propel-development+unsubscribe@googlegroups.com<propel-development%2Bunsubs cribe@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/propel-development
I'm fairly new to the group, although i have been using propel from some time now. I think it's one of the best things in PHP. Didn't knew that the only one contributing to development was François, If needed i will like to contribute some how. Always thought that the only thing missing in propel was a graphical editor for XML databases definitions. Just an idea...
>> I fully agree with Leon: if Propel would be a one-man project, this is not >> because of anything François has done. On the contrary: if François wasn't >> doing what he is doing, Propel would be what is was a few months ago: a >> zero-man project.
>> I sometimes wonder whether Propel is too complicated to work as a >> collaborative project. Creating these intuitive interfaces is hard work, >> which is not easily discussed if you only have text (and English is not your >> native language, as is the case for many of us). Sometimes sitting around a >> physical notebook and a lot of hand-waving is what you need to describe >> these bigger ideas. On the other hand, many other projects are able to pull >> this off (the Linux kernel, to name one at the far edge of the "complicated" >> scale), so why not Propel?
>> If the community is not involved enough, it's because we, the individuals >> who make up the community, do not show enough effort. I did this for a >> while, following the Propel timeline RSS feed, and commenting on things that >> I did not understand, which lead to some improvements. At the time François >> gave me SVN access (with the pun subject "Would you like to commit >> yourself?"), I dropped out. Maybe because I got stage fright, maybe because >> I got a little behind on the timeline and never caught up, which made me get >> out of touch with the daily development, which increased the fear that I >> would do something that would not fit in with the rest (is this an argument >> for a distributed VCS?).
>> But today I say "to hell with my fears!" I will join Leon on his quest to >> expand the use of Criteria in joins (and from-clauses?), by acting as his >> sparring partner and commenting on his ideas. Partly because it is a large >> but separate chunk of work, partly because we can discuss the harder stuff >> in Dutch, and partly because his work for the government interests me (maybe >> we can do similar things in Belgium - multiple times, with all the >> governments we have!).
>> So Leon, you can expect a mail from me soon. And François, I hope this is >> the answer you needed to your mail: yes, I will commit myself. In fact, I >> think I just did.
> Thank you for your contribution !
> François work is very good, keep up the good work.
> Bye
>> Greetings,
>> Jan Fabry
>> PS: Niklas, I once created a web-based "Propel generator" that created the >> schema files and PHP classes from a database schema (because my colleagues >> feared the XML schema). It should not be too hard to adapt this to create a >> "Propel comparison tool", where you can load a schema and let different >> Propel versions generate the PHP files, so they can be compared. This could >> solve the confusion around your problem, and prevent it from happening >> again. Is there anyone who wants to contribute to Propel by creating this?
>> On 21 Jun 2010, at 09:53, LvanderRee wrote:
>> > Hello Niklas/all,
>> > Regarding the community-nature of Propel. I already tried many times, >> > very hard, to get some feedback regarding several issues, but usually >> > only François is the one who is responding to my messages. I tried >> > irc, trac and this mailinglist but all without any feedback.... >> > Currently I am working on improving the functionality for defining >> > joins: >> > http://www.propelorm.org/ticket/878#comment:10
>> > So if we don't want it to become a one man show, I wonder what else I >> > have to do to get some community feedback...
>> > Regards >> > Leon
>> >> Please don't get me wrong. I appreciate the great work you've done for >> >> Propel. I just hope Propel isn't going to be too much a one man project >> >> where changes aren't discussed at all (IRC is a great place..) and all >> >> the community effort is just done by opening tickets for you to fix.
>> >> Niklas
>> -- >> You received this message because you are subscribed to the Google >> Groups "Propel Development" group. >> To post to this group, send email to propel-development@googlegroups.com >> To unsubscribe from this group, send email to >> propel-development+unsubscribe@googlegroups.com<propel-development%2Bunsubs cribe@googlegroups.com> >> For more options, visit this group at >> http://groups.google.com/group/propel-development
> -- > You received this message because you are subscribed to the Google > Groups "Propel Development" group. > To post to this group, send email to propel-development@googlegroups.com > To unsubscribe from this group, send email to > propel-development+unsubscribe@googlegroups.com<propel-development%2Bunsubs cribe@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/propel-development
Speaking of what propel is missing, do either if the contributed patForms, or PEAR form generators still work with the 1.5 branch? Anyone have anything they've used. I took a crack at writing my own, and it OK, but I definitely would rather help out on an existing solution.
- Alex
On 6/22/10, Agustín Quiroga <agusquir...@gmail.com> wrote:
> I'm fairly new to the group, although i have been using propel from some > time now. I think it's one of the best things in PHP. > Didn't knew that the only one contributing to development was François, If > needed i will like to contribute some how. > Always thought that the only thing missing in propel was a graphical editor > for XML databases definitions. Just an idea...
>>> I fully agree with Leon: if Propel would be a one-man project, this is >>> not >>> because of anything François has done. On the contrary: if François >>> wasn't >>> doing what he is doing, Propel would be what is was a few months ago: a >>> zero-man project.
>>> I sometimes wonder whether Propel is too complicated to work as a >>> collaborative project. Creating these intuitive interfaces is hard work, >>> which is not easily discussed if you only have text (and English is not >>> your >>> native language, as is the case for many of us). Sometimes sitting around >>> a >>> physical notebook and a lot of hand-waving is what you need to describe >>> these bigger ideas. On the other hand, many other projects are able to >>> pull >>> this off (the Linux kernel, to name one at the far edge of the >>> "complicated" >>> scale), so why not Propel?
>>> If the community is not involved enough, it's because we, the individuals >>> who make up the community, do not show enough effort. I did this for a >>> while, following the Propel timeline RSS feed, and commenting on things >>> that >>> I did not understand, which lead to some improvements. At the time >>> François >>> gave me SVN access (with the pun subject "Would you like to commit >>> yourself?"), I dropped out. Maybe because I got stage fright, maybe >>> because >>> I got a little behind on the timeline and never caught up, which made me >>> get >>> out of touch with the daily development, which increased the fear that I >>> would do something that would not fit in with the rest (is this an >>> argument >>> for a distributed VCS?).
>>> But today I say "to hell with my fears!" I will join Leon on his quest to >>> expand the use of Criteria in joins (and from-clauses?), by acting as his >>> sparring partner and commenting on his ideas. Partly because it is a >>> large >>> but separate chunk of work, partly because we can discuss the harder >>> stuff >>> in Dutch, and partly because his work for the government interests me >>> (maybe >>> we can do similar things in Belgium - multiple times, with all the >>> governments we have!).
>>> So Leon, you can expect a mail from me soon. And François, I hope this is >>> the answer you needed to your mail: yes, I will commit myself. In fact, I >>> think I just did.
>> Thank you for your contribution !
>> François work is very good, keep up the good work.
>> Bye
>>> Greetings,
>>> Jan Fabry
>>> PS: Niklas, I once created a web-based "Propel generator" that created >>> the >>> schema files and PHP classes from a database schema (because my >>> colleagues >>> feared the XML schema). It should not be too hard to adapt this to create >>> a >>> "Propel comparison tool", where you can load a schema and let different >>> Propel versions generate the PHP files, so they can be compared. This >>> could >>> solve the confusion around your problem, and prevent it from happening >>> again. Is there anyone who wants to contribute to Propel by creating >>> this?
>>> On 21 Jun 2010, at 09:53, LvanderRee wrote:
>>> > Hello Niklas/all,
>>> > Regarding the community-nature of Propel. I already tried many times, >>> > very hard, to get some feedback regarding several issues, but usually >>> > only François is the one who is responding to my messages. I tried >>> > irc, trac and this mailinglist but all without any feedback.... >>> > Currently I am working on improving the functionality for defining >>> > joins: >>> > http://www.propelorm.org/ticket/878#comment:10
>>> > So if we don't want it to become a one man show, I wonder what else I >>> > have to do to get some community feedback...
>>> > Regards >>> > Leon
>>> >> Please don't get me wrong. I appreciate the great work you've done for >>> >> Propel. I just hope Propel isn't going to be too much a one man >>> >> project >>> >> where changes aren't discussed at all (IRC is a great place..) and all >>> >> the community effort is just done by opening tickets for you to fix.
>>> >> Niklas
>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Propel Development" group. >>> To post to this group, send email to propel-development@googlegroups.com >>> To unsubscribe from this group, send email to >>> propel-development+unsubscribe@googlegroups.com<propel-development%2Bunsubs cribe@googlegroups.com> >>> For more options, visit this group at >>> http://groups.google.com/group/propel-development
>> -- >> You received this message because you are subscribed to the Google >> Groups "Propel Development" group. >> To post to this group, send email to propel-development@googlegroups.com >> To unsubscribe from this group, send email to >> propel-development+unsubscribe@googlegroups.com<propel-development%2Bunsubs cribe@googlegroups.com> >> For more options, visit this group at >> http://groups.google.com/group/propel-development
> -- > You received this message because you are subscribed to the Google > Groups "Propel Development" group. > To post to this group, send email to propel-development@googlegroups.com > To unsubscribe from this group, send email to > propel-development+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/propel-development
> I fully agree with Leon: if Propel would be a one-man project, this is not because of anything François has done. On the contrary: if François wasn't doing what he is doing, Propel would be what is was a few months ago: a zero-man project.
> I sometimes wonder whether Propel is too complicated to work as a collaborative project. Creating these intuitive interfaces is hard work, which is not easily discussed if you only have text (and English is not your native language, as is the case for many of us). Sometimes sitting around a physical notebook and a lot of hand-waving is what you need to describe these bigger ideas. On the other hand, many other projects are able to pull this off (the Linux kernel, to name one at the far edge of the "complicated" scale), so why not Propel?
> If the community is not involved enough, it's because we, the individuals who make up the community, do not show enough effort. I did this for a while, following the Propel timeline RSS feed, and commenting on things that I did not understand, which lead to some improvements. At the time François gave me SVN access (with the pun subject "Would you like to commit yourself?"), I dropped out. Maybe because I got stage fright, maybe because I got a little behind on the timeline and never caught up, which made me get out of touch with the daily development, which increased the fear that I would do something that would not fit in with the rest (is this an argument for a distributed VCS?).
> But today I say "to hell with my fears!" I will join Leon on his quest to expand the use of Criteria in joins (and from-clauses?), by acting as his sparring partner and commenting on his ideas. Partly because it is a large but separate chunk of work, partly because we can discuss the harder stuff in Dutch, and partly because his work for the government interests me (maybe we can do similar things in Belgium - multiple times, with all the governments we have!).
> So Leon, you can expect a mail from me soon. And François, I hope this is the answer you needed to your mail: yes, I will commit myself. In fact, I think I just did.
> Greetings,
> Jan Fabry
> PS: Niklas, I once created a web-based "Propel generator" that created the schema files and PHP classes from a database schema (because my colleagues feared the XML schema). It should not be too hard to adapt this to create a "Propel comparison tool", where you can load a schema and let different Propel versions generate the PHP files, so they can be compared. This could solve the confusion around your problem, and prevent it from happening again. Is there anyone who wants to contribute to Propel by creating this?
> On 21 Jun 2010, at 09:53, LvanderRee wrote:
> > Hello Niklas/all,
> > Regarding the community-nature of Propel. I already tried many times,
> > very hard, to get some feedback regarding several issues, but usually
> > only François is the one who is responding to my messages. I tried
> > irc, trac and this mailinglist but all without any feedback....
> > Currently I am working on improving the functionality for defining
> > joins:
> >http://www.propelorm.org/ticket/878#comment:10 > >http://groups.google.com/group/propel-development/browse_thread/threa...
> > I mentioned it on irc as well, but no feedback what so ever...
> > So if we don't want it to become a one man show, I wonder what else I
> > have to do to get some community feedback...
> > Regards
> > Leon
> >> Please don't get me wrong. I appreciate the great work you've done for
> >> Propel. I just hope Propel isn't going to be too much a one man project
> >> where changes aren't discussed at all (IRC is a great place..) and all
> >> the community effort is just done by opening tickets for you to fix.
As for the use case you describe (a simple self-referencing foreign key), the generated method names are unchanged between 1.5.1 and 1.5.2. There is a unit test for that, and it passes.
It's likely that you have other (symmetrical) foreign keys in the same table. So this is the same explanation as before: method names change only if you have symmetrical foreign keys, whch didn't work properly in previous 1.5.x releases.
Once again, I am very sorry that the upgrade breaks your code, but: 1 - the goal was to fix a bug, and your 1.5.1 code couldn't do a few things because of that 2 - the fix for the regression is easy: add a phpName and a refPhpName to the broken foreign keys in your schema to match the old method names.
By the way, it's such a good practice to define relation names in foreign keys that I wonder if we shouldn't enforce it.
As for discussing the changes, I'm all for it - and I think I have already done it.
> This is completely untrue. The only relation names that changed are those > of symmetrical relations, that used to break ModelQueries in Propel 1.5 ( > http://www.propelorm.org/ticket/968).
> These symmetrical relations are an uncommon (and, if you want my opinion, > bad) way to design a model, yet Propel decided to support them fully in > 1.5.2, because they were supported in 1.4.
> So the problem is that something that used to work seamlessly in 1.4 didn't > work the same in 1.5.0. And 1.5.0 had all the beta/RC/whatever release cycle > you want, yet this problem was only discovered a after the stable release.
> Ok, I stand corrected.
> Byt I can still prove my point. I started a project with 1.5.0b1 (or it > might have been 1.5 HEAD before the official releases). It has a schema like > the following:
> This generated from the early 1.5 versions to 1.5.1 foreign references like > Item::getItemReferencedByParentItemId() or something similar (and the same > goes for the query classes).
> Now when I upgraded to 1.5.2 90% of my queries got broken because the > foreign reference changed it's name! And this was between a maintenance > release!
> Even if this was a bugfix and needed for 1.4 BC it did change the behaviour > of generator between a maintenance release. People just don't expect things > like this to happen when upgrading a maintenance release.
> Now, if someone wants to help with writing more unit tests to make Propel > even more robust, I'd be the first to applause.
> François
> Please don't get me wrong. I appreciate the great work you've done for > Propel. I just hope Propel isn't going to be too much a one man project > where changes aren't discussed at all (IRC is a great place..) and all the > community effort is just done by opening tickets for you to fix.
> Niklas
> -- > You received this message because you are subscribed to the Google > Groups "Propel Development" group. > To post to this group, send email to propel-development@googlegroups.com > To unsubscribe from this group, send email to > propel-development+unsubscribe@googlegroups.com<propel-development%2Bunsubs cribe@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/propel-development
Thanks for your message, you said it better than I would :)
Propel is a community project. For me, it means that that anyone can contribute to it, if he/she adheres to the base principles. It does not mean that a piece of code can't be committed until the whole community agrees to it - that would be a still project.
> I fully agree with Leon: if Propel would be a one-man project, this is not > because of anything François has done. On the contrary: if François wasn't > doing what he is doing, Propel would be what is was a few months ago: a > zero-man project.
> I sometimes wonder whether Propel is too complicated to work as a > collaborative project. Creating these intuitive interfaces is hard work, > which is not easily discussed if you only have text (and English is not your > native language, as is the case for many of us). Sometimes sitting around a > physical notebook and a lot of hand-waving is what you need to describe > these bigger ideas. On the other hand, many other projects are able to pull > this off (the Linux kernel, to name one at the far edge of the "complicated" > scale), so why not Propel?
> If the community is not involved enough, it's because we, the individuals > who make up the community, do not show enough effort. I did this for a > while, following the Propel timeline RSS feed, and commenting on things that > I did not understand, which lead to some improvements. At the time François > gave me SVN access (with the pun subject "Would you like to commit > yourself?"), I dropped out. Maybe because I got stage fright, maybe because > I got a little behind on the timeline and never caught up, which made me get > out of touch with the daily development, which increased the fear that I > would do something that would not fit in with the rest (is this an argument > for a distributed VCS?).
> But today I say "to hell with my fears!" I will join Leon on his quest to > expand the use of Criteria in joins (and from-clauses?), by acting as his > sparring partner and commenting on his ideas. Partly because it is a large > but separate chunk of work, partly because we can discuss the harder stuff > in Dutch, and partly because his work for the government interests me (maybe > we can do similar things in Belgium - multiple times, with all the > governments we have!).
> So Leon, you can expect a mail from me soon. And François, I hope this is > the answer you needed to your mail: yes, I will commit myself. In fact, I > think I just did.
> Greetings,
> Jan Fabry
> PS: Niklas, I once created a web-based "Propel generator" that created the > schema files and PHP classes from a database schema (because my colleagues > feared the XML schema). It should not be too hard to adapt this to create a > "Propel comparison tool", where you can load a schema and let different > Propel versions generate the PHP files, so they can be compared. This could > solve the confusion around your problem, and prevent it from happening > again. Is there anyone who wants to contribute to Propel by creating this?
> On 21 Jun 2010, at 09:53, LvanderRee wrote:
> > Hello Niklas/all,
> > Regarding the community-nature of Propel. I already tried many times, > > very hard, to get some feedback regarding several issues, but usually > > only François is the one who is responding to my messages. I tried > > irc, trac and this mailinglist but all without any feedback.... > > Currently I am working on improving the functionality for defining > > joins: > > http://www.propelorm.org/ticket/878#comment:10
> > So if we don't want it to become a one man show, I wonder what else I > > have to do to get some community feedback...
> > Regards > > Leon
> >> Please don't get me wrong. I appreciate the great work you've done for > >> Propel. I just hope Propel isn't going to be too much a one man project > >> where changes aren't discussed at all (IRC is a great place..) and all > >> the community effort is just done by opening tickets for you to fix.
> >> Niklas
> -- > You received this message because you are subscribed to the Google > Groups "Propel Development" group. > To post to this group, send email to propel-development@googlegroups.com > To unsubscribe from this group, send email to > propel-development+unsubscribe@googlegroups.com<propel-development%2Bunsubs cribe@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/propel-development
But one component needs to be kept: dbd2propel. So the only work to do is to port this one to a Propel task in the core, and ditch the whole contrib/ directory.
> Speaking of what propel is missing, do either if the contributed > patForms, or PEAR form generators still work with the 1.5 branch? > Anyone have anything they've used. I took a crack at writing my own, > and it OK, but I definitely would rather help out on an existing > solution.
> - > Alex
> On 6/22/10, Agustín Quiroga <agusquir...@gmail.com> wrote: > > Hi all,
> > I'm fairly new to the group, although i have been using propel from some > > time now. I think it's one of the best things in PHP. > > Didn't knew that the only one contributing to development was François, > If > > needed i will like to contribute some how. > > Always thought that the only thing missing in propel was a graphical > editor > > for XML databases definitions. Just an idea...
> >>> I fully agree with Leon: if Propel would be a one-man project, this is > >>> not > >>> because of anything François has done. On the contrary: if François > >>> wasn't > >>> doing what he is doing, Propel would be what is was a few months ago: a > >>> zero-man project.
> >>> I sometimes wonder whether Propel is too complicated to work as a > >>> collaborative project. Creating these intuitive interfaces is hard > work, > >>> which is not easily discussed if you only have text (and English is not > >>> your > >>> native language, as is the case for many of us). Sometimes sitting > around > >>> a > >>> physical notebook and a lot of hand-waving is what you need to describe > >>> these bigger ideas. On the other hand, many other projects are able to > >>> pull > >>> this off (the Linux kernel, to name one at the far edge of the > >>> "complicated" > >>> scale), so why not Propel?
> >>> If the community is not involved enough, it's because we, the > individuals > >>> who make up the community, do not show enough effort. I did this for a > >>> while, following the Propel timeline RSS feed, and commenting on things > >>> that > >>> I did not understand, which lead to some improvements. At the time > >>> François > >>> gave me SVN access (with the pun subject "Would you like to commit > >>> yourself?"), I dropped out. Maybe because I got stage fright, maybe > >>> because > >>> I got a little behind on the timeline and never caught up, which made > me > >>> get > >>> out of touch with the daily development, which increased the fear that > I > >>> would do something that would not fit in with the rest (is this an > >>> argument > >>> for a distributed VCS?).
> >>> But today I say "to hell with my fears!" I will join Leon on his quest > to > >>> expand the use of Criteria in joins (and from-clauses?), by acting as > his > >>> sparring partner and commenting on his ideas. Partly because it is a > >>> large > >>> but separate chunk of work, partly because we can discuss the harder > >>> stuff > >>> in Dutch, and partly because his work for the government interests me > >>> (maybe > >>> we can do similar things in Belgium - multiple times, with all the > >>> governments we have!).
> >>> So Leon, you can expect a mail from me soon. And François, I hope this > is > >>> the answer you needed to your mail: yes, I will commit myself. In fact, > I > >>> think I just did.
> >> Thank you for your contribution !
> >> François work is very good, keep up the good work.
> >> Bye
> >>> Greetings,
> >>> Jan Fabry
> >>> PS: Niklas, I once created a web-based "Propel generator" that created > >>> the > >>> schema files and PHP classes from a database schema (because my > >>> colleagues > >>> feared the XML schema). It should not be too hard to adapt this to > create > >>> a > >>> "Propel comparison tool", where you can load a schema and let different > >>> Propel versions generate the PHP files, so they can be compared. This > >>> could > >>> solve the confusion around your problem, and prevent it from happening > >>> again. Is there anyone who wants to contribute to Propel by creating > >>> this?
> >>> On 21 Jun 2010, at 09:53, LvanderRee wrote:
> >>> > Hello Niklas/all,
> >>> > Regarding the community-nature of Propel. I already tried many times, > >>> > very hard, to get some feedback regarding several issues, but usually > >>> > only François is the one who is responding to my messages. I tried > >>> > irc, trac and this mailinglist but all without any feedback.... > >>> > Currently I am working on improving the functionality for defining > >>> > joins: > >>> > http://www.propelorm.org/ticket/878#comment:10
> >>> > So if we don't want it to become a one man show, I wonder what else I > >>> > have to do to get some community feedback...
> >>> > Regards > >>> > Leon
> >>> >> Please don't get me wrong. I appreciate the great work you've done > for > >>> >> Propel. I just hope Propel isn't going to be too much a one man > >>> >> project > >>> >> where changes aren't discussed at all (IRC is a great place..) and > all > >>> >> the community effort is just done by opening tickets for you to fix.
> >>> >> Niklas
> >>> -- > >>> You received this message because you are subscribed to the Google > >>> Groups "Propel Development" group. > >>> To post to this group, send email to > propel-development@googlegroups.com > >>> To unsubscribe from this group, send email to > >>> propel-development+unsubscribe@googlegroups.com<propel-development%2Bunsubs cribe@googlegroups.com> > <propel-development%2Bunsubscribe@googlegroups.com<propel-development%252Bu nsubscribe@googlegroups.com>
> >> -- > >> You received this message because you are subscribed to the Google > >> Groups "Propel Development" group. > >> To post to this group, send email to > propel-development@googlegroups.com > >> To unsubscribe from this group, send email to > >> propel-development+unsubscribe@googlegroups.com<propel-development%2Bunsubs cribe@googlegroups.com> > <propel-development%2Bunsubscribe@googlegroups.com<propel-development%252Bu nsubscribe@googlegroups.com>
> > -- > > You received this message because you are subscribed to the Google > > Groups "Propel Development" group. > > To post to this group, send email to propel-development@googlegroups.com > > To unsubscribe from this group, send email to > > propel-development+unsubscribe@googlegroups.com<propel-development%2Bunsubs cribe@googlegroups.com> > > For more options, visit this group at > > http://groups.google.com/group/propel-development
> -- > You received this message because you are subscribed to the Google > Groups "Propel Development" group. > To post to this group, send email to propel-development@googlegroups.com > To unsubscribe from this group, send email to > propel-development+unsubscribe@googlegroups.com<propel-development%2Bunsubs cribe@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/propel-development
On 23 Jun 2010, at 10:52, Francois Zaninotto wrote:
> By the way, it's such a good practice to define relation names in foreign keys that I wonder if we shouldn't enforce it.
Were you thinking of all foreign keys or only symmetrical keys? I would not like enforcing names on all relations, since this would probably result in the same names in many cases, and reverse-engineering tasks would still need to make up a name. It would also (slightly) increase the effort required to get a simple Propel example running.
Maybe we should offer a "strict" or "good practices" check on the schema? One you can run at any time, which gives diagnostics and suggestions about your schema without actually needing to build it. Like setting relation names, but maybe also about indexes and so? Of course, you could create a build option that forces you to pass this check for the build to continue, but I would not enable this by default.
True, it's no use working one a relation name builder that works in every situation and then throwing an exception everytime the user forgets to define its own relation name :)
> On 23 Jun 2010, at 10:52, Francois Zaninotto wrote:
> > By the way, it's such a good practice to define relation names in foreign > keys that I wonder if we shouldn't enforce it.
> Were you thinking of all foreign keys or only symmetrical keys? I would not > like enforcing names on all relations, since this would probably result in > the same names in many cases, and reverse-engineering tasks would still need > to make up a name. It would also (slightly) increase the effort required to > get a simple Propel example running.
> Maybe we should offer a "strict" or "good practices" check on the schema? > One you can run at any time, which gives diagnostics and suggestions about > your schema without actually needing to build it. Like setting relation > names, but maybe also about indexes and so? Of course, you could create a > build option that forces you to pass this check for the build to continue, > but I would not enable this by default.
> Greetings,
> Jan Fabry
> -- > You received this message because you are subscribed to the Google > Groups "Propel Development" group. > To post to this group, send email to propel-development@googlegroups.com > To unsubscribe from this group, send email to > propel-development+unsubscribe@googlegroups.com<propel-development%2Bunsubs cribe@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/propel-development
