If transparent persistence is persistence where you don't need to make any special cases in your object model for persistence puporses (somehting nothing actually does), maybe translucent persistence is when you get a couple odd restrictions that enable vast improvements. JDO 1.0.1 would fall in this category with the PersistenceCapable pucky.
I have been thinking more and more about doing PC like behavior as it opens up so many options for optimization it is downright silly. Compile steps are annoying, but... acceptable. Aspect systems provide the needed hooks in a much better API than straight bytecode enhancement. Seriously thinking about things like that. A huge thing is the simple question "is it okay if when you store a transient object you get back a proxy which is transactionally bound instead of the same instance you stored?" If the answer is yes we can blow toplink/hibernate/ojb performance out of the water =)
2 writebacks [/src/java] permanent link
OJB added two committers -- Robert Sfeir and Martin Kalen!
8 writebacks [/tech] permanent link
I thought I was going to go sit through a painful bashing in a session subtitled "Evolution from SQL to OJB to Hibernate" -- but it wasn't =) The session actually got reasonably technical, showed real examples, etc. Their OJB info was a touch dated (they didn't know about anonymous keys) but was pretty accurate in general, and they definately know their stuff. Not surprised, they have been using it probably as long as I have =)
They pointed a few very nice things H does which we don't (though I am not sure of one, need to check as it is a config piece I never use). All in all, good session. Hibernate came out smelling better, I think, but it is better in some cases (er, when you really like SQL ;-).
The main thing I really walked away from was the incredibly importance of perceived project momentum. They pointed out, honestly, that momentum on OJB is not as high as on Hibernate. I agree. I have been working to change that, and believe OJB momentum is ramping up again. We had a really ugly 1.0rc roll. Ugly ugly. Basically we broke the key rule of "release often."
That said, everyone on OJB has been holding onto code waiting for the 1.0.X (bugfix) branch to be made so we can start cleaning up a lot of stuff in the 1.1 branch. With the release of the JDO 2 draft spec we can start looking at that. They got rid of the bytecode enhancement requirement, yea!
A huge thing that they touched on but didn't really explicit point out is that a big difference between OJB and Hibernate is that OJB wants to work with standards and Hibernate wants to become a standard. The things that are important to us are not the same as the things important to the Hibernaters, and that matters.
3 writebacks [/tech] permanent link
Sat in on a good session on AspectWerkz, then bumped into Jonas in the bookstore (browsing minutes before closing looking for deals). Got to interrogate him =) Okay, not interrogate, but ask about aspect instantiation at least. Sounds like it solves a big problem I have been continually running into. Will try porting our application aspects over when I get back to work and see how it goes.
0 writebacks [/tech] permanent link
I was actually able to meet with a relatively new OJB user today and give him an hour and a half tutorial. It was really nice. In that time we got it working, doing basic CRUD, and got a bunch of decent learning tests in for him. It was very fun =) He was still a student, working on a summer internship project, and his level of knowledge (not skill!) reminded me of a lot of things.
Ant is not easy when you are new to it. "We" tend to think of ant like driving nails -- you learn it, and never think about it again. That learning it part is important. Ditto JUnit. Ditto the quirks between the two =)
The audience for most apps is not a super-experienced developer, but is a somewhat experienced developer. Stepping through things this afternoon with this guy (remaning nameless as I don't know if he wants to be named =) was fantastic because it is really hard to see things you know well from a newcomer's perspective. You get close to the problem, and close to the tools, and realize the edge cases you know (flush cache in unit tests to make sure you hit db when you are testing mappings) and don't think about are not explicit or obvious to other people.
=)
11 writebacks [/tech] permanent link
Excuse really. Knee was hurting. Got bad. Went to doctor. Now on enough medicine to probably cure the black plague. Moving leg hurts a great deal =/
Read any rants with that in mind. Also understand "lots of antibiotics" == "no beer at GroovyOne"
See, crankiness =)
0 writebacks [/tech] permanent link
I guess I am cranky today, I am ranting a lot. Okay, here is another one. Sun seems to be betting that most people at J1 are stupid. Here is why:
If I weren't here as a speaker presenting to the unwashed masses I would be pretty darned insulted, and might have a word with whoever at Sun would listen to me.
Of course, if they are right, the "Corporate Developers" laying down 1.6 grand to be here won't be quick enough to notice, after all, they are here to see how Sun is trying to make a LFM more LFMier.
0 writebacks [/tech] permanent link
Great, now there are 4 object/relational mapping "standards" going into the java[x].*.* namespaces.
On a seriouser note, JDBC4 == commons-dbutils with some annotation sugar and XML. It is SQL for VBScript. I don't think really hacking database code (which in the java world is apparently people doing O/R (possibly to one of the 4 official standards, and 1 unofficial standard (if hibernate is a standard like TSSS would have you think ;-))) will use any of the new stuff aside from the SQL 03 support =/ It is SQL for VBScript programmers. Certainly useful, but in jdbc?
Actually, it is worse. Right now when people want to do raw sql they *usually* externalize it. Now it sits in annotations which require a recompile and hunting through sourcecode to find. I guess you could do:
public ResultSet @Query { sql="{query}" } find(String query);
but that is bleeding silly and i don't think would work as I suspect the variable binding is only for prepared statement population.