Jacopo Cappellato wrote: > Hi Adam, > > On Mar 18, 2010, at 4:18 PM, Adam Heath wrote: > >> Jacopo Cappellato wrote: >>> Hi Adam, >>> >>> please see my comments inline: >>> >>> On Mar 17, 2010, at 9:22 PM, Adam Heath wrote: >>> >>>> Sorry, no. I don't even have to try to know this isn't correct. You >>>> haven't done proper deprecation on the entity. >>>> >>> calm down, you don't even know what you are talking about. >> >> http://cwiki.apache.org/confluence/display/OFBTECH/General+Entity+Overview >> >> Look at deprecated entities. >> >> ... >> When changing an entity significantly, and especially when changing >> the primary key, always deprecate the existing entity and create a new >> one so that an upgrade path for existing databases is possible. To >> facilitate this in addition to deprecating the old entity (prefixing >> with "Old") and defining the new one you should always create a >> service to move data from the old entity to the new one. The service >> doesn't have to figure out when to run itself (which is tough to >> figure out and generally not reliable), and generally should be made >> to be run manually. >> ... > > Pointing your finger at me and feeling strong because you have the "Holy Book > Of Policies" in your hand? > I am joking but as you know I know this best practice; in fact I have > considered it carefully but then, as I explained in my last email, in this > specific situation my judgment told me it was not necessary because the > OrderShipment entity was only part of an incomplete process I implemented > time before (and could not be used in production as is). > I may be wrong, but not because of that generic best practice; we can > (politely) discuss specific issues you are having and then I am sure we will > find out the best way to go.
Are you discussing your ItemIssuance to OrderShipment change? If so, I'm not. OrderShipment has been in existance for a long long time. It has been released into the wild. It was referenced by lots of places for at least several years. It has been used in production environments. Therefore, any changes to the primary key of that entity have to be handled with care. This was not done. >> OrderShipment has been used for ages, long before our last release. >> And you didn't follow the proper procedure for changing the primary >> key. The procedure is to rename the entity when the primary key >> fields changed. > > Again, you don't know what you are talking about, see my comments below... I absolutely do. I've looked at the svn history. There's no way to argue that. It's available for anyone to see, if they just look in the past. I see it referenced in versions that were from released versions of ofbiz. It's been used by production systems. Care must be taken. >>> These are exactly the same steps you have to run after the changes I did - >>> no extra work is required because of my approach. >>> >>> Now, in my self-defense (your tone seems to imply that you have setup a >>> trial on me, the rope is hanging ready for me), I decided to not use the >>> deprecation pattern for two reasons: >>> a) no code was using the OrderShipment entity, no code apart from some old >>> code (that I wrote) related to manufacturing shipment plans: a process that >>> was only partially implemented for manufacturing companies implementing a >>> particular type of fulfillment based on order/manufacturing schedules; I >>> doubt you or anyone else were using this (and for sure not in production >>> because it was not functional complete until my recent changes) >>> b) I have decided to keep the entity model cleaner: we can't limit the >>> OFBiz grow being stuck on code that others could have built outside of >>> OFBiz and kept proprietary; if third parties are doing this then it's fine, >>> they will have to fix the code after the upgrade (I am sure they are >>> prepared for doing this, even if you are not) >> I see tons of references to OrderShipment. >> >> For example, >> applications/product/webapp/facility/WEB-INF/actions/shipment/EditShipmentPlan.groovy >> mentioned OrderShipment, with lines that were modified on 2008-06-13, >> revision 667640. This change was a conversion from bsh to groovy, so >> this entity was even in use well before that. > > Yes, this is exactly what I was referring to: that code is used to define a > "shipment plan" (see my previous email), I contributed it a lot of time ago. So, you are admitting that the code has been in use for years. Yet you don't see the need to implement proper deprecation of the OrderShipment entity(not ItemIssuance). >>> That said, if you follow my notes you will probably resolve most of the >>> issues you are experiencing and most of all you will help me to test the >>> migration script (in fact I could run it only in a couple of servers so it >>> is still experimental). But we have to be collaborative, relaxed: pointing >>> fingers, judging others' work and screaming is not the right way to >>> interact... at least not the right way to interact with *me*, so please >>> avoid doing this from now on, it really annoys me. >> It's not about *me* following procedure. I can do that. I can handle >> entity changes. But I'm not the only one using ofbiz. > > I don't understand your response. There are other people out there in this big blue world of ours that don't follow this mailing list. They will see a new version of ofbiz get released, and go: "woo! time to schedule an upgrade in a year from now, after we've had a chance to read over all the changes and digest what they mean." So when they finally get around to doing this upgrade, your change will be 1.5 years old, and they themselves will be working with their original ofbiz that is 2.5 years old(or older). > >> You are lucky I discovered this problem before we released. > > Lucky? Lucky, because we need to fix it before we release, not after. >> This is a change that happened during this development cycle, and *must* be >> fixed before our next release. >> > > I am not going to take orders from you but I am very open at accepting > suggestions and in fact I would like to get the opinion also from other > committers, persons like David, Adrian, Anil, Scott etc... with much more > experience than you on the OFBiz applications and on business processes in > general. If they also think that we should deprecate the entity and replace > it as you suggest I will not object and I promise that, before the next > official release containing this code will be released, I will implement the > proper code. Do you really want to play that card? Really? This has nothing to do with ofbiz application experience. This is a procedure for all of ofbiz, not just the applications. Yes, it is true, that you haven't seen either Ean or I discussing in public various ofbiz applications. That doesn't mean we haven't been using them. Remember, we have been involved for years. The first major site we did used an ofbiz from january, 2003. And I'm the one who wrote a major chunk of the view entity cache clearing code.
