Geoff Hambrick

author
+ Follow
since Jul 22, 2008
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Geoff Hambrick

This thread also reminds me of the time we used to deliberately rollback read transactions to eliminate all the overhead of the commits in terms of logs, etc. Still probably a reasonable thing to do in many cases.

Ok then, Geoff
It seems like it is an attribute (constraint) on a subtype of event whether it is for a single couple, teams, etc. The difference between each type of event manifests in the relationship to Couples and/or Teams that can register. You might call the target of the relationship "Entrant", which has Couple, Team, etc as subtypes. The reason you may want two hierarchies is to enable you to enforce the constraint. Otherwise, Teams could sign up for Couples only Events and vice versa.

Interestingly enough, rather than complicating things, it actually simplifies them a bit, as you can use the underlying datastore to help you enforce the constraint rather than do it in code.

Ok then, Geoff

For the "blue line", it is useful to think of the relationships on your object model as requirements for accessibility, so, if you need to be able to get from an Event to the individual Person(s), then there is a derived relationship shown on the diagram. At design time, you would likely exploit a honking big join in the underlying data store to come up with the list.
We cover JDO in the history section, and how it was one of the threads that led to the JPA specification.

JPA is given a chapter where we evaluate it against the template in chapter four that we extracted from the discussion of persistence issues in the first three chapters.

Ok then, Geoff
Was as much of a space constraint as a time based one.

See my related post for more details.

Ok then, Geoff
Thanks Mike.

We felt Open JPA would get folks into the ballpark of what JPA provides as a general framework, and enable them to download our code samples and try it for themselves.

Then, if they like JPA and are looking for support, they can go looking for commercially available ones.

It might be interesting to post this comment on the developerworks book site so that folks are aware of the availability.

Ok then, Geoff
We focus on the features of Hibernate Core and only really mention Spring in passing. Amazon is one site that has everything you are looking for:

http://www.amazon.com/Persistence-Enterprise-Guide-Technologies-developerWorks/dp/0131587560

Google Persistence in the Enterprise for others.

Ok then, Geoff
The focus is on object - relational mappings, which means that you have to read between the lines to apply the issues to COBOL (and other procedural languages) and HDAM and other non-relational datastores.

Chapter two is about the only purely general one, as it discusses the business drivers and IT requirements that will impact your selection.

Ok then Geoff
Absolutely. Chapter three outlines a common example, and chapter four a questionnaire that we use in the evaluation chapters (5-9) to show how each framework can be used to sole the same basic "meet in the middle" mapping problem for a true apples to apples comparison. Chapter 10 summarizes the evaluations, showing the features from each side by side.

Ok then, Geoff
We take an end-to-end view of persistence in enterprise applications, from the business drivers to the functional and non functional requirements. The first part of the book gives the background to understand the questions you should ask, the kinds of answers you tend to get, and the ramifications of each in terms of tradeoffs. From this we create a questionnaire that becomes a template for evaluation that we use to analyze five different frameworks, and which you can also use to drive your selection criteria. This same template is used in the summary chapter to give a side by side comparison.

As far as I know, no other book takes this kind of "wholistic" view.

Ok then, Geoff
We don't include performance measurements as a basis of comparison, but we do include features of each framework that enable you to tune it.

Ok then, Geoff

Originally posted by Ravikiran Vishnuvajhala:


Geoff,

One more question to this is - does it also list down the pros and cons of these frameworks, for example: performane, scalability, rapid application development, flexibility and maintainability etc?



Yes. The questionnaire that we used for the evaluation template includes "non functional" aspects like the abilty to tune for performance, what kind of tooling is used to support development, how easy it is to maintain, etc.

Ok then, Geoff

Originally posted by Jesus Angeles:
Have you mentioned, if any, upcoming new age of persistence technologies, on top, or totally different from orm and jdbc? Are there alternatives to orm and jdbc currently?

Or to put it another way, are there other persistence technologies mentioned other than orm and jdbc (e.g. stored procedures)?

[ July 22, 2008: Message edited by: Jesus Angeles ]



Yes. The reason we included PureQuery is that it represents a style similar to SQLJ where the calls to the database are directly included in the program code.

Ok then, Geoff

Originally posted by Mike Keith:


Respectfully, how can you do a serious book on persistence and performance and not include TopLink, arguably the seminal and most mature product in the ORM persistence space? There are some very common use cases where TopLink outperforms every other persistence strategy you have listed.



We share your pain.

We originally wanted to include chapters on both Toplink and EJB 2.0, especially the latter since I wrote a column called the "EJB Advocate" on developer works that discusses various issues associated with proper exploitation of the framework.

Chapter 1 discusses the History of ORM Mapping and gives proper homage to TopLink (and EJBs). It also explains why we chose the 5 we did -mainly to get the most "modern" of each type of framework that is in wide use.

We decided that the purpose of the book was not to be a "how to" guide for the various technologies (since specific books can do a much better job), but a "when to guide" (as to when each best applies).

The questionnaire that we outline in Chapter 4 and use to evaluate the five frameworks in Chapters 5-9 can be used to evaluate TopLink or any other framework we skipped. But more importantly, it can be used to evaluate new frameworks in the future, so hopefully, the book will be useful long after the five we evaluate have been relegated to history.

Cold comfort, I know, but rest assured that Persistence in the Enterprise is a serious book that covers the issues you will encounter in determining which type of framework best applies in the context of concrete examples.

Ok then, Geoff
Not to lose a sale, but for new development where there is no "legacy" framework such as Hibernate already being used, we would recommend JPA as it represents the standard going forward. The History of ORM mapping describes how Hibernate drove the new JPA standard.

Ok then, Geoff
The intro is titled "Why you should steal this book (ith apologies to Abbie Hoffman).

But that is not the real reason. Besides what Rolands covers, we have found that the questionaire in Chapter 4 is good for driving requirements gathering in new projects to insure that nothing is missed. Not all will apply of course to every project. But that, plus the details in the following chapters will help you better exploit the framework you have chosen.

Also, we have found that knowing why you chose a given framework will help you better understand if there are compelling reasons to switch to another one.

And if you take the hint in Chapter 10 about applying Pattern Based Engineering, you can often fill the holes in your current framework yourself...

Ok then, Geoff