- Support for difficult impedance mismatch mapping issues that occur such as when the classes and database don’t match
- Support for handling different relationship modeling settings for a model
- Unrestricted support for the mapping of complex and even multiple class inheritance hierarchies including mapping override
- Support for proprietary SQL for each databasedialect
- Support for sharing maps across business POJOs
- Support for sharing maps across applications
- Support for custom types and custom proxy behaviors for data population
- Support for custom relationship lazy handling
- Support for re-routing SQL within the same mapping
- Stored procedure support in the mapping, etc.
THOUGHT Inc has announced the integration of the Spring Application Development Framework with version 5.0 of CocoBase PURE POJO, their Dynamic Object to Relational Mapping tool. The new integration expertly ties CocoBase into the Spring Generic Transaction and DAO Exception Hierarchies providing access to an enterprise-level ORM solution. CocoBase focuses on delivering an easy to use tool for the full range of simple to complex POJO persistence requirements typically seen in enterprise-level corporate applications. The combination of Coco Base's high performance and GUI workbench for even the most difficult persistence requirements has been estimated to save projects up to $3 for every $1 spent on CocoBase. Developers get the benefits of a commercial-grade mature and stable O/R Mapping architecture shipping since 1997 with rapid response technical support, comprehensive training, architectural mentoring, strong sales support, exhaustive documentation, and continuous technical innovation. The unique approach of Spring to isolate persistence in the application makes it easy to switch from one ORM tool to another, offering persistence tool independence. Thus developers can start using CocoBase PURE POJO in their Spring applications right now. Rod Johnson noted in his article titled "Introduction To The Spring Framework" that "...ORM solutions have different performance and other characteristics, and there is no perfect one size fits all solution. Alternatively, you may find that certain functionality is just not suited to an implementation using your ORM tool. Thus it makes sense to decouple your architecture from the tool-specific implementations of your data access object interfaces. If you may ever need to switch to another implementation for reasons of functionality, performance, or any other concerns, using Spring now can make the eventual switch much easier. Spring's abstraction of your ORM tool's Transactions and Exceptions, along with its IoC approach which allow you to easily swap in mapper/DAO objects implementing data-access functionality, make it easy to isolate all ORM-specific code in one area of your application, without sacrificing any of the power of your ORM tool." CocoBase PURE POJO offers an ORM solution for Spring framework developers. Coco Base’s architecture was designed from the beginning to handle the complexities of enterprise-level corporate applications with the required flexibility and extensibility. The CocoBase architecture provides a powerful yet simple to use approach for persisting data that decouples the object from being hard-coded to the database. CocoBase takes the database specific code and prewritten SQL out of the object and saves this information to the mapping layer (i.e. map). This dynamic mapping layer provides amazing flexibility as well as a multitude of performance and scaling optimizations that are easily changed by the programmer to best fit their specific requirements. CocoBase POJO persistence runs typically faster than hand-coded JDBC with identical commands and SQL statements; without using caching, combined calls or other tricks. When you add Caching, etc. performance increases another 400% to 1,000% and more. CocoBase’s linear performance characteristics means that applications can scale and retain the same performance, not slow or bog down as ORM tools without this feature do. Here are examples of often overlooked complex enterprise ORM requirements that CocoBase easily supports which saves the developer from having to write extra code just to get their current solutions to work:
- Posted by: Greg Baker
- Posted on: October 18 2006 11:36 EDT
- Re: Spring Gets High Performance With CocoBase V5 by jelmer kuperus on October 18 2006 14:16 EDT
- Spring Gets High Performance With CocoBase V5 by Corby Page on October 18 2006 14:18 EDT
- Re: Spring Gets High Performance With CocoBase V5 by Jacques Ledoux on October 18 2006 22:30 EDT
- Man, what was I doing all this time without "High Performance" by Tim O'Brien on October 22 2006 16:38 EDT
- Re: Man, what was I doing all this time without "High Performanc by Javier Pavier on October 23 2006 01:10 EDT
I can't think of a single good reason to even consider this product with free high quality products like hibernate, toplink essentials etc out there. Oh wait there's one https://www.theserverside.com/news/thread.tss?thread_id=20376#89229 Does cocobase support jpa yet btw ?
I am very happy to see Thought Inc. continuing their proud tradition of integration and support for open source infrastructure: Oh, and lets not forget that with CocoBase you get a product based on internationally recognized landmark patents. Anyone who brings [open source software] into their company should know that it makes their company legally and financially responsible for any and all patent and copyright violations. Open Source Zealots who believe it should be legal to steal software ideas won't care about this, but real companies with real business bottom line issues should be made aware of the potential consequences of this arrogance. Violations of patents can involve punitive damages as well as the cost of lost sales to the patent holder (IBM is another patent holder and after the SCO issue they might look to increase their revenues). Just ask the 1000 or so companies who just received the SCO letters about user liability. Companies that choose this development approach should be aware that they're legally playing craps. Patents are the current law - and that's fine if an engineer wants to act with civil disobedience because they don't believe software should be patented - but it doesn't change the fact that both the engineer and the company where they're employed are breaking the law if patents are violated... It most definitely is a SERIOUS issue - and to believe anything different is delusional. To disregard the risk is simply foolish and shortsighted for companies... Ward Mullins CTO THOUGHT Inc. http://www.thoughtinc.com That is so scary, every time I read it I still crap my pants and uninstall Spring!
That is so scary, every time I read it I still crap my pants and uninstall Spring!Yeah, trying to scare your potential customers into submission and coughing up is just great PR.. :D The only guys getting away with that is probably the IRS and certain italian "families"..
Oh, and lets not forget that with CocoBase you get a product based on internationally recognized landmark patents. ....(blah blah blah)What's that, you want everyone to boycott Cocobase? Excellent. Who's going to use Cocobase now? (sound of crickets chirping)
Since he mentioned SCO, let me quote their latest 10K filing: http://ir.sco.com/secfiling.cfm?filingID=1104659-06-60911 We do not have a history of profitable operations. Our year ended October 31, 2003 was the first full year we were profitable in our operating history. Our profitability for the year ended October 31, 2003 resulted primarily from our SCOsource business. For the years ended October 31, 2005 and 2004, we incurred net losses applicable to common stockholders of $10,726,000 and $16,227,000, respectively, and for the nine months ended July 31, 2006 we incurred a net loss of $12,855,000. As of July 31, 2006, our accumulated deficit was $247,797,000. It's interesting to note that the initial round of extortion resulted in the only profitable year in the history of the company (their lawsuit was filed March 6, 2003). And at their current burn rate, they have barely over a year left before they will be forced to dissolve. (Though they may find some VCs who are willing to continue to gamble to keep them alive until their lawsuits are officially dead.) You can make claims of engineer's civil disobedience all you want, but the reality is that attempting to extort companies with anything but rock solid patent/copyright claims will not work. It will simply result in endless litigation that will eventually bury the company with the least amount of money. (Though it will make some law firms very rich in the process.)
It is rather curious that a company who tried to scare people off open-source software makes such an announcement three years later. Their "expertly tied integration" into Spring generic transaction and DAO Exception Hierarchies is nothing more than what is already available for JDBC, Hibernate, JDO, Ibatis, etc directly from Spring experts themselves. Of course, Thought had Spring's source to help them achieve such and "expert integration". It's funny that M. Mullins is not coming out as loudly as he did to make a case for open-source but this annoucement is nevetherless a direct admission of his total misjudgement few years ago. Moreover, the annoucement almost sounds like this CocoBase integration will enhance Spring's offering while it is obvious that CocoBase is trying to surf on the popularity and excellence of the other. The one thing that I totally agree with however is the acknowledgement of the capacity of "Spring to isolate persistence in the application makes it easy to switch from one ORM tool to another". Where I do disagree is with their outcome estimation where I think that this "expert integration" will help more people establish an orderly path to move out of CocoBase than for some to move in. Finally, the list of special features at the end is certainly nothing to make me write to my mother about or even consider this commercial product over the open-source ORM solutions I alreasy use or that are openly available. Also, looking at the way M. Mullins talks about his competition is certainly no motivation to become one of his captive customer. So my conclusion to this is that this company must be going through tough times to swallow the bullet of this infamous post and to try that hard to make buddy-buddy with open-source community. The problem is that they don't seem to have much to offer...
You know, i've got all these applications out there running in Spring, and I thought everything was fine, then I came across the headline "Spring Gets High Performance With CocoBase V5", and it just ruined my days. I thought that Spring came bundled with "High Performance", but I just checked the documentation, and, YOU ARE TOTALLY RIGHT, the section entitled "High Performance" is missing. Darn it, and here I thought I was ready to take on the world. I'll definitely be using CocoBase, especially if it supplies all the High Performance I need for my enterprise applications.
I thought that Spring came bundled with "High Performance", but I just checked the documentation, and, YOU ARE TOTALLY RIGHT, the section entitled "High Performance" is missing.I'd watch what you say. Ward Mullins has exclusive international copyright on that term. Sorry couldnt resist :-)