Entity, MappedSuperclass, and Embeddable
by Gail Badner
There is a discussion about XML overriding rules in Section 12.2 of the JPA 2.0 spec.
Are the following overrides possible?
1) Can an @Entity annotation be overridden using XML <mapped-superclass> or <embeddable>?
2) Can a @Mappedsuperclass annotation be overridden using XML <entity> or <embeddable>?
3) Can a @Embeddable annotation be overridden using XML <entity> or <mapped-superclass>?
Supporting this would obviously affect the Hierarchical domain info.
If any of these overrides are valid, then we should discuss this at the Tuesday morning meeting.
Regards,
Gail
14 years, 10 months
Lets move dev meeting 4/25
by Steve Ebersole
This Sunday is Easter and I am guessing some folks will not be available
that Monday. So lets move our weekly dev meeting to Tuesday the 26th,
same time.
Some items to consider for discussion:
1) proposed SessionFactory building apis
2) what to do with EJB3Configuration?
3) package name changes, core is moving along, but i do not think any
other modules have even been started. Do we want to do that in bulk?
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
14 years, 10 months
HV: Considering static vs. runtime type for property path creation
by Gunnar Morling
Hi guys,
there was an interesting question on the Validator forum
(https://forum.hibernate.org/viewtopic.php?f=9&t=1010626&start=0)
which IMO boils down to the question whether the static or the runtime
type of an association should be considered when creating property
paths in case of cascading validations.
An example:
class Foo {
private Collection<Bar> bar1 = new ArrayList<Bar>();
private List<Bar> bar2 = new ArrayList<Bar>();
}
When validating an instance of Foo (which has invalid elements in
bar1/bar2) with HV, the resulting property path node for bar1 would be
iterable but not indexable ("bar1[]"), while the property path node
for bar2 would be iterable and indexable ("bar2[123]"). This is that
way because the static type of bar1/bar2 (Collection vs. List) is
considered when building the nodes, and not the runtime type
(ArrayList in both cases).
That said, basing the path on the runtime type instead would seem
reasonable to me, too (as for instance the constraints to validate are
also determined based on the runtime type of references). I scanned
through the BV spec. (section 4.5) but didn't find a clear answer
which approach should be followed. Are there any opinions on that?
Thanks,
Gunnar
14 years, 10 months
logging
by Steve Ebersole
As hopefully everyone is aware by now we have switched over to use JBoss
Logging for our logging api in 4.0. JBoss Logging provides 2 unique
capabilities that we for sure wanted to leverage and I think I am just
now starting to come to grasp with. So I wanted to discuss some stuff
related to them.
The first capability is built in i18n support.
The second is the idea of keyed messages. Each message has a consistent
alphanumeric key by by which you can, for example, refer to the
condition that caused the particular log message in say documentation.
Additionally as with most logging frameworks, you have a notion of a
logger or category.
All logging ends up targeting different audiences. Some messages are
meant directly for the developer and are meant to aid them during
development ("hey you messed up this mapping construct"). Others are
meant to help admin/support folks understand what is going on in a
running system that might be causing problems.
In my opinion, there are other natural things to do here depending on
which audience is being targeted. Take category names, for example; for
developer-centric messages I think using the name of the originating
class (current scheme) makes the most sense; but for other audiences
having consistently named categories that can survive package
reorganization and so can be better documented in user docs is a bug win.
There is an inherent design decision in JBoss Logging that if you use
the stuff in the most straight forward way, you end up limited to a
single category scheme and limiting yourself to trace and debug logging
for the developer audience and info/warn/error for "admin" audience. So
the question I ask is whether we want to just go that route, or if we
want to invest in a quite possibly over-engineered approach were we
cater to this idea of separate channels.
The big issue to me is the lack of granularity in "developer targeted
messages". This goes hand in hand with quick dev/test cycles. As an
illustration, I cranked up logging to (mostly) TRACE during a run of the
hibernate-core test suite, which took approx 13 minutes. Dropping that
log level back down to INFO and the test suite ran in 2 minutes. That
is significant.
What would the alternative look like?
Well in JBoss Logging, i18n is provided by means of a proxied interface.
Hibernate defines this interface and provides it to JBoss Logging:
@MessageLogger( projectCode = "HHH" )
public interface CoreMessageLogger extends BasicLogger {
@LogMessage(level=INFO)
@Message(value="Hello %s", id=1)
void sayHello(String name);
...
}
CoreMessageLogger log = Logger.getMessageLogger(
CoreMessageLogger.class,
this.getClass()
);
(the second argument is the category name, here our class name)
So again, with just those pieces we have the intended JBoss Logging
setup. You would have a boat load of messages at TRACE/DEBUG the
develop needs to see so they still need to "crank up the logging". Now
luckily the category is still friendly here in that respect since they
can define which classes/packages on which to crank up the logging.
So an alternative is to use this notion of channels:
@MessageLogger( projectCode = "HHH" )
public interface CoreAdminMessageLogger extends BasicLogger {
@LogMessage(level=INFO)
@Message(value="Hello %s", id=1)
void sayHello(String name);
...
}
@MessageLogger( projectCode = "HHH" )
public interface CoreDevMessageLogger extends BasicLogger {
@LogMessage(level=INFO)
@Message(value="Loading the HelloComponent implementation %s", id=501)
void loadingHelloComponent(String implementationName);
...
}
CoreAdminMessageLogger adminLog = Logger.getMessageLogger(
CoreAdminMessageLogger.class,
"org.hibernate.core.hello"
);
CoreDevMessageLogger devLog = Logger.getMessageLogger(
CoreDevMessageLogger.class,
this.getClass()
);
I realize this all seems over-engineered in many ways. I do see *some*
benefit. I guess the decision I need help weighing is whether this
amount of benefit out-weighs the "complexity".
Thoughts?
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
14 years, 10 months
Hibernate Search 3.4: Faceting, perf and more
by Emmanuel Bernard
We are pleased to announce our latest baby: Hibernate Search 3.4.
The big new feature is faceting: this is what you see on Amazon when you do a query and they propose the matching list of brands, price range etc.
The other big trend is performance improvement thanks to our users / customers feedback.
Red it all on http://goo.gl/7yrgq
Emmanuel
14 years, 10 months
cacheable files
by Steve Ebersole
Do we want to make caching of files a flag for processing all of the xml
files?
Currently we have methods:
addFile(String path)
addFile(File file)
addCacheableFile(String path)
addCacheableFile(File file)
Could we instead condense these and allow configuration of whether to
try and cache xml files?
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
14 years, 10 months
JDBC / Dialect thoughts
by Steve Ebersole
I dont have great concept-names for these yet, but i wanted to start a
discussion about a new set of thoughts running around in my head.
Essentially they relate to interacting with the JDBC Connection. The
current state of things is that we rely on the Dialect to know how to
perform those operations. But the Dialect is static information and so
cannot account for database configuration differences, for example. Its
why we end up with so many MySQL based dialects for example.
We have had a number of requests from Dialect developers/maintainers to
allow the Dialect to initialize itself from a Connection. But I still
agree we should avoid that.
However, I do think we need a way to allow Dialects to understand and
account for specifics of the underlying database.
Another thing that plays here is the expanded JDBC4 DatabaseMetadata,
now that master (4.0) can rely on Java 6. Take
DatabaseMetaData#locatorsUpdateCopy as an example. Using it we know how
to handle LOB data (mostly) when writing it to JDBC. Really we just
need the dialect to tell us if the DatabaseMetadata methods are
accurately implemented in the driver. I see this as a common them
starting to emerge.
So I started thinking about a class which manages all this for us. In
fact, we may already have such a class in
org.hibernate.engine.jdbc.spi.JdbcServices.
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
14 years, 11 months
Gradle IntelliJ generation
by Steve Ebersole
I just pushed some fixes to the IntelliJ project generation from Gradle
(thanks Szczepan for the help!). It now works much better out of the
box. You still have to set up copyrights and possibly codestyles
depending on how you defined codestyles.
Until Gradle 1.0-milestone-3 is released, you should use the gradlew
command to run the IntelliJ generation (it uses a Gradle SNAPSHOT):
./gradlew idea
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
14 years, 11 months
