[Search] Search 5 and architecture review
by Hardy Ferentschik
Hi,
IMO we should rethink how we describe the architecture of Search and especially its extension points.
I think for Search 5 we will need to review/rewrite the documentation (maybe as part of moving to asciidoc) and clear out some
of the ambiguities we have in the used terminology.
For example, ‘backend’. Technically it is the implementation of BackendQueueProcessor, but I think we sometimes used the
term in the wrong context as well, for example when we talk about the "Infinispan backend” which is really a DirectoryProvider.
Speaking of the latter, my understanding is that we wanted to move away from DirectoryProvider (at least from a configuration/
documentation point of view) and consistently refer to IndexManager.
These are just two examples of various major and minor inconsistencies in how we describe Search. I think we really should
spend some time and work out the terminology we want to use and weed out the documentation. Maybe this is something
everyone can just keep in mind for a while to think about.
Should we create an issue for this where we can collect ideas on what needs to be changed?
—Hardy
12 years, 3 months
[Search] Spatial still experimental
by Hardy Ferentschik
Hi,
Given that we are moving to Search 5 and we made some recent adjustments, I am wondering whether it would
not be time to remove the experimental status of the spatial Api now? Thoughts?
—Hardy
12 years, 3 months
JDK8 build jobs!
by Sanne Grinovero
I've installed a preview build of JDK8 on ci.hibernate.org, and
created jobs for:
- ORM
- OGM
- Search
Gunnar is adding Validator.
There are some exceptions that we should investigate; one of them is
Animal Sniffer breaks.
I've debugged it and came to the conclusion it doesn't work because it
uses ASM to actually inspect the bytecode, and it should use ASM 5 to
be able to parse the bytecode produced by the Java8 build.
Ideally we should build with Java7 (since we'll be releasing with
Java7) and then run the tests only with Java8, but having concluded
that it's not a JDK8 regression but simply a limitation of the plugin
being outdated, I've opted for running these builds with:
-Danimal.sniffer.skip=true
We should look at the other failures now: we could implement
workarounds in our code, but it's of higher value to identify
potential regressions in the JDK and report these quickly: that would
allow people to move on to Java8 even when they are stuck with an
older release of our libraries.
Cheers,
Sanne
12 years, 3 months
Limited beta access to Gitter
by Sanne Grinovero
Gitter is a new service aiming to replace IRC, and specifically meant
for OSS projects team working with Github.
I've got an invitation to participate to the beta, and got it setup
for these chatrooms (open to the public):
- https://gitter.im/hibernate/hibernate-orm
- https://gitter.im/hibernate/hibernate-search
I've setup integration from Jenkins and Github so we should get
notifications in the chatroom about commits, PRs, reviews and build
jobs (totally untested so far)
Shall we give it a try?
Some features which I'm liking:
- it provides a per-repository chatroom and an organization wide chatroom
- history is always available, cloud stored and full-text searchable.
so we can jump to one device to the next or stay offline and catch up
- has native clients for Mac, iOS, Android (but I'm using the webpage
which works great and has desktop notifications via Chrome)
- no new accounts: you login via GitHub, so your permissions on the
chatroom are inherited from your permissions on the respective
repositories
- people join following just the links above.. very low hassle for newcomers!
I'll be there and on IRC as well in the foreseeable future.
Cheers,
Sanne
12 years, 3 months
Hibernate ORM : master, metamodel, 4.3 and 5.0
by Steve Ebersole
Just a quicks heads up about some work Gail and I will be doing in the
ORM repo today. Mainly the time has come to transition (back) to 5.0
development. We have submitted our passing JPA 2.1 TCK results to
Oracle, but are still awaiting response back from them; once we get
approval from them, I will be releasing 4.3 Final.
So the following concrete things will happen in the next few days:
1) I will create a 4.3 branch from the 4.3.0.CR2 tag. I will use this
to re-tag 4.3.0.CR2 as-is as 4.3.0.Final (thanks Gail for the idea!).
After I get 4.3 Final released I will port all the changes between CR2
and master HEAD to this new 4.3 branch.
2) Gail will work on getting the metamodel branch rebased against
current master. After the steps above are complete, we will (ff) merge
that work to master and push upstream. At that point master will
represent 5.0 development. We will drop metamodel branch.
Let us know any questions/concerns...
12 years, 3 months
[OGM] Precedence of options specified on different levels
by Gunnar Morling
Hi,
In the context of embedded associations for CouchDB [1], I'm working on
support for configuring the association storage mode using our new option
system [2]. I can see the following "axes" of configuration here:
* via annotation
- on an association property
- on a type
* via the option API
- on an association property
- on a type
- on the global level
* via a configuration property as given via OgmConfiguration,
persistence.xml etc.
* on super-types
- via annotations or API
- on the property or entity level
I'm looking now for a sensible and comprehensible algorithm for taking
these sources of configuration into account and determining the effective
setting for a given association. This could be one way:
1) check API
a) look for a setting given via the programmatic API for the given
property
b) if the property is not configured, look for a setting given for the
entity
c) if the entity itself is not configured, repeat a) and b) iteratively
on super-types if present
d) if no type from the hierarchy is configured look for the global setting
2) check annotations
if no configuration could be found in 1), do the same for annotations,
i.e.
a) look for configuration on the given property
b) look for configuration on the given entity
c) repeat a) and b) iteratively on super-types if present
3) take default value given via OgmConfiguration/persistence.xml etc.
This algorithm ensures that:
* API configuration always takes precedence over annotation configuration;
e.g. if a super-type is configured via the API or the setting is given on
the API global level, any annotations are ignored
* "More local" configuration takes precedence; i.e. a type's own
configuration wins over configuration from super-types, property-level
configuration wins over entity-level configuration
Note that any setting given via OgmConfiguration/persistence.xml would be
handled as last fallback option, i.e. any configuration given via
annotations or the API would take precedence over that. I first didn't like
that but I came to think it makes sense, if the property name conveys that
semantics, e.g. "defaultAssociationStorageMode".
Any other thoughts or alternative approaches around this?
Thanks,
--Gunnar
[1] https://hibernate.atlassian.net/browse/OGM-389
[1] https://hibernate.atlassian.net/browse/OGM-208
12 years, 3 months
