Greetings all, I have to agree with Mike. There is a lot of good to be had in the Cayenne project, and the discuss there of. For starters, it identifies the need in our community for the stability of a good ORM that is well defined and stable, connected to a good web object generating framework, and if possible connecting today's customers. WebObjects, EOF and CoreData have that advantage for the Apple side of the house, and even the Android camp can consume a WebObjects app.
There was a reason I suggested using a standards body for accomplish the feat of having an Open Source ORM, be it Cayenne, EOF, or something else. The concept is that it would be stable like a rock, and public there by enable any one to use it. Standards take time to form, but in the process there are projects like Cayenne, and prototypes using WO/EOF to demonstrate the concepts what we think an ORM should be. EOF is the de facto ORM by its age, but it could easily be supplanted by derived versions found in Ruby, Python, and other languages. My dissertation gave EOF a good head start by putting on the map in the academic community, and I am about to publish it. The Cayenne project is not the only project that I have up for consideration by the Open Grid Forum that is of interest to the WO community. The Zion project is also significant aspect, too. If I could have some community backing both, that would be fabulous. If Apple would like to help that would be nice too, assuming they read these things. Since Zion is a WO/ Mac/ iOS hybrid all together thing, I would hope they would see the wisdom and value in the product. The Zion project itself is a Texas Tech project that is the fruit of my dissertation, and I hope that I will see it to market and success some way (Just a dream). V/R, Dan Beatty, Ph.D. Texas Tech University, Alumni dan.bea...@mac.com https://sites.google.com/site/allnightstarparty/home (806)438-6620 On Jul 13, 2012, at 11:41 AM, Mike Schrag wrote: > don't make decisions based on anecdotal evidence > > ms > > On Jul 13, 2012, at 9:03 AM, Karl <kgret...@mac.com> wrote: > >> Hi, >> >> Making EOF multi-threaded is really not that desirable nor is it necessary. >> EOF gets most of its speed and efficiency through its 'cut through' >> single-threaded design at the Access layer. >> >> About 4 years ago, Apple tested an internal build of WO/EOF that was fully >> multi-threaded. It was about half as fast as the EOF that we know (and >> love?). Since then, Apple's internal version of EOF retains virtually the >> current implementation except for the snapshot layer which is now shared by >> multiple DB stacks. So the solution was to remove the 1-1 relationship >> between DB stacks and snapshots and to retain the cut-through >> single-threaded design of EOF. >> >> Karl >> >> On 2012-07-13, at 3:06 PM, Farrukh Ijaz <farrukh.i...@fuegodigitalmedia.com> >> wrote: >> >>> Sorry for late response, just landed last night. >>> >>> The idea is very simple to understand and implement. E.g. I've a third >>> party library which has a method named with following signature: >>> >>> String encode(String someString) { >>> // some crappy encoding performed on someString and saved as encoded... >>> return encoded; >>> } >>> >>> Now this method can be private, public, protected, static, final, blah blah >>> etc. I find that encoding is buggy, how to fix it? There are two ways: >>> >>> 1. Get the source code, fix the method and submit patch. (This is sometimes >>> not possible and for sure not possible in case of WebObjects) >>> 2. Use AOP >>> >>> Forget about option 1. In Option 2 we have to use some AOP mechanism and >>> the one that I've tested with my Wonder apps is AspectJ. I'm not going into >>> details as it's a vast subject but providing links which are sufficient to >>> experiment :) >>> >>> http://www.eclipse.org/aspectj/ >>> http://www.eclipse.org/aspectj/doc/released/progguide/starting-aspectj.html#the-dynamic-join-point-model >>> >>> As far as weaving is concerned, I would suggest to use dynamic join point >>> as they can be used to intercept calls and invoke different code rather >>> than modifying the original classes. >>> >>> The idea is we need to define join point for the method which is buggy or >>> where we want to provide our own implementation. When the code is executed, >>> the class loader reroutes the request for incoming method calls to our >>> code. AOP is different that OOP. In contrast with OOP where methods are >>> associated with Objects, AOP is used to classify those methods under common >>> aspects and normally we use regular expressions for that. Two very common >>> aspects I can explain here: >>> >>> 1. You may have lots of methods and you want to collect execution type for >>> each method call. (A logging aspect) >>> 2. A developer like me who put all the code in try block and catch one >>> super Exception, someone would like to perform different operations on each >>> sub-exception can write an aspect to catch my exceptions and do whatever he >>> wants and then continue the original processing. >>> >>> I'm not familiar with internals of the WebObjects but the code that's >>> responsible for single thread can be studied and multithreaded solution can >>> be provided using AOP. If someone is interested to work with me to on this, >>> I'm more than happy to help where I can :) >>> >>> Farrukh >>> >>> On 2012-07-11, at 10:25 PM, Chuck Hill <ch...@global-village.net> wrote: >>> >>>> Hi Farrukh, >>>> >>>> I like the idea of using AOP to address bugs in WO. Can you give us any >>>> details on how you did that? >>>> >>>> As for making EOF multi-threaded.... that is a very fundamental part of >>>> the design. Fixing that with AOP would be challenging. :-) >>>> >>>> >>>> Chuck >>>> >>>> >>>> >>>> On 2012-07-11, at 11:12 AM, Farrukh Ijaz wrote: >>>> >>>>> Hi, >>>>> >>>>> In past I've used AOP to address issues of closed source. This I believe >>>>> if carefully used can help convert the EOF from single to multi threaded >>>>> and/or solve other bottleneck problems. Having said this doesn't mean I'm >>>>> against Cayane. However if the current EOF issues get fixed with AOP >>>>> patched code would be better for those who don't want to or for some >>>>> reasons can't switch to Cayane. >>>>> >>>>> Farrukh >>>>> >>>>> Chuck Hill <ch...@global-village.net> wrote: >>>>> >>>>>> I agree that we need to more closely examine Cayenne before jumping in >>>>>> with both feet. How mature are the tools? What is the functionality >>>>>> gap? How important is the missing functionality? How costly is adding >>>>>> any needed functionality? Will the missing functionality fit in with >>>>>> the Cayenne architecture? How stable is it? How well does it scale >>>>>> (scaling is more than multi-threaded EOF)? And Cayenne is only >>>>>> EOAccess/EOControl. What do we do about the presentation layer? >>>>>> Getting rid of 2/3 of WO still leaves you with WO. >>>>>> >>>>>> >>>>>> Chuck >>>>>> >>>>>> On 2012-07-11, at 11:29 AM, Theodore Petrosky wrote: >>>>>> >>>>>>> >>>>>>> Hurray someone actually started talking about this. >>>>>>> >>>>>>> >>>>>>> I want to add my two cents without starting a "this is better than >>>>>>> that" conversation. >>>>>>> >>>>>>> If Cayenne is to be utilized, someone in the know must look not only at >>>>>>> the current state of Cayenne, but at the developers. What is/was their >>>>>>> philosophy behind what they write/wrote? If we don't, it will be a very >>>>>>> short and costly marriage. Costly, because we either buck up and foot >>>>>>> the bill to rewrite Webobjects or continue in a bad relationship. >>>>>>> >>>>>>> I am writing this not as a diatribe but because I am concerned that in >>>>>>> the excitement of looking at Cayenne, the obvious impact of differing >>>>>>> philosophies of the original authors may be ignored. BTW, I say >>>>>>> original authors because the person that wrote the first line of code >>>>>>> left his/her imprint on the direction of all code that follows. >>>>>>> >>>>>>> JMHO (i mean that sincerely). >>>>>>> >>>>>>> Ted >>>>>>> >>>>>>>> Message: 4 >>>>>>>> Date: Wed, 11 Jul 2012 10:09:08 -0500 >>>>>>>> From: John Huss <johnth...@gmail.com> >>>>>>>> To: WebObjects-Dev Mailing List List <webobjects-dev@lists.apple.com> >>>>>>>> Subject: Migrating from EOF to Cayenne >>>>>>>> Message-ID: >>>>>>>> >>>>>>>> <CAOUwSGtOwEayxK4im97HucAUANo=cfnrkq9ej5z+679bcd7...@mail.gmail.com> >>>>>>>> Content-Type: text/plain; charset="windows-1252" >>>>>>>> >>>>>>>> At WOWODC there was a lot of interest in migrating from EOF >>>>>>>> to Cayenne, and >>>>>>>> even entirely rebasing Wonder to run on top of Cayenne >>>>>>>> instead of EOF. >>>>>>>> >>>>>>>> *Why would anyone want to do this? * >>>>>>>> >>>>>>>> 1. Cayenne is open-source and is actively >>>>>>>> being developed >>>>>>>> 2. Cayenne has great concurrency support >>>>>>>> which is in stark contrast to >>>>>>>> EOF single-threaded architecture >>>>>>>> 3. Cayenne is conceptually very similar to >>>>>>>> EOF so the transition is >>>>>>>> fairly straightforward >>>>>>>> >>>>>>>> For those reasons it is a much better long term solution >>>>>>>> than EOF, which is >>>>>>>> now frozen in time. Cayenne can be used inside a WO >>>>>>>> application as an EOF >>>>>>>> replacement while continuing to use the rest of WebObjects. >>>>>>>> >>>>>>>> *I'm interested. Now what?* >>>>>>>> >>>>>>>> - Learn about Cayenne. The best source of >>>>>>>> information for comparing EOF >>>>>>>> and Cayenne is on the >>>>>>>> wiki<http://wiki.wocommunity.org/display/WO/Alternative+Technologies-Cayenne>. >>>>>>>> In addition, you can look at the >>>>>>>> documentation<http://cayenne.apache.org/>for >>>>>>>> Cayenne. >>>>>>>> - Use Cayenne in your new projects. >>>>>>>> Cayenne runs just fine inside a >>>>>>>> WebObjects application. Wonder has >>>>>>>> the ERCayenne framework and >>>>>>>> ERCayenneExample to help you get started. >>>>>>>> I suggest working with the trunk >>>>>>>> of the Cayenne source (and Wonder too) >>>>>>>> since some things are just being >>>>>>>> added to make this easier. >>>>>>>> - Help work on easing and automating the >>>>>>>> migration from EOF to Cayenne. >>>>>>>> It is possible to automate a large part of >>>>>>>> the work involved in moving from >>>>>>>> EOF to Cayenne. But it requires effort. >>>>>>>> ERCayenne in Wonder has a class >>>>>>>> that will convert an EOModel to a Cayenne >>>>>>>> model (the class is >>>>>>>> CayenneConverter). This works well, but >>>>>>>> could be improved. I've started >>>>>>>> working on an Eclipse refactoring script >>>>>>>> that will convert from one API to >>>>>>>> the other. Yes, you may not have known (I >>>>>>>> didn't) that Eclipse can record a >>>>>>>> series of refactorings and save it as a >>>>>>>> script. The bulk of the migration >>>>>>>> work is creating refactoring scripts in >>>>>>>> Eclipse by performing refactorings >>>>>>>> on a stubbed out version of the EOF API to >>>>>>>> convert the API into the >>>>>>>> equivalent Cayenne API. After performing >>>>>>>> the refactorings, a script can be >>>>>>>> exported using Refactor->"Create >>>>>>>> Script". For EOF methods that do not have >>>>>>>> a direct Cayenne equivalent, helper >>>>>>>> methods (or classes) will need to be >>>>>>>> written that can serve as a direct >>>>>>>> replacement. >>>>>>>> >>>>>>>> *How can I help specifically with the migration effort?* >>>>>>>> >>>>>>>> - CayenneConverter in ERCayenne (for >>>>>>>> converting the model) does not >>>>>>>> convert the connection dictionaries in the >>>>>>>> EOModel yet. >>>>>>>> - CayenneConverter does a poor job >>>>>>>> converting fetch specs defined in the >>>>>>>> model currently. >>>>>>>> - We need to create new subclasses of >>>>>>>> Cayenne's DbAdapter that use the >>>>>>>> Wonder naming convention for primary key >>>>>>>> generators/sequences. This is done >>>>>>>> by subclassing classes like >>>>>>>> PostgresPkGenerator and overriding >>>>>>>> sequenceName. This is necessary to >>>>>>>> support existing databases created with >>>>>>>> EOF. >>>>>>>> - An Wonder-like entity template is >>>>>>>> already in ERCayenneExample. This >>>>>>>> needs to be examined and any missing >>>>>>>> functions from WonderEntity need to be >>>>>>>> added. For example, I know some the >>>>>>>> .deleteAllXXXXRelationships and >>>>>>>> .createXXXX(…) methods are missing. >>>>>>>> - More refactorings need to created. For >>>>>>>> example, a refactoring script >>>>>>>> should be made that changes NSArray and >>>>>>>> NSDictionary methods to the >>>>>>>> equivalent List or Map APIs (since Cayenne >>>>>>>> doesn't use these classes for >>>>>>>> relationships or fetch results you >>>>>>>> probably want to minimize the places you >>>>>>>> need them). >>>>>>>> - Submit code to Cayenne or create >>>>>>>> Jira<https://issues.apache.org/jira/browse/CAY>issues >>>>>>>> >>>>>>>> Any questions? :-) >>>>>>>> >>>>>>>> John >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net >>>>>>> >>>>>>> This email sent to ch...@global-village.net >>>>>> >>>>>> -- >>>>>> Chuck Hill Senior Consultant / VP Development >>>>>> >>>>>> Practical WebObjects - for developers who want to increase their overall >>>>>> knowledge of WebObjects or who are trying to solve specific problems. >>>>>> http://www.global-village.net/gvc/practical_webobjects >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Do not post admin requests to the list. They will be ignored. >>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>>>> Help/Unsubscribe/Update your Subscription: >>>>>> https://lists.apple.com/mailman/options/webobjects-dev/farrukh.ijaz%40fuegodigitalmedia.com >>>>>> >>>>>> This email sent to farrukh.i...@fuegodigitalmedia.com >>>> >>>> -- >>>> Chuck Hill Senior Consultant / VP Development >>>> >>>> Practical WebObjects - for developers who want to increase their overall >>>> knowledge of WebObjects or who are trying to solve specific problems. >>>> http://www.global-village.net/gvc/practical_webobjects >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/kgretton%40mac.com >>> >>> This email sent to kgret...@mac.com >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.com >> >> This email sent to msch...@pobox.com > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/danielbeatty%40mac.com > > This email sent to danielbea...@mac.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
