ci.hibernate.org and network port assignment
by Sanne Grinovero
I've created WEBSITE-178 [1] as once again we had testsuites failing
because of a network port being used by a different job; bad luck, but
we can do better.
Assuming we want to use the Jenkins plugin "port allocator", this
would however need to be consistently honored by all builds we launch:
it passes variables which we should use, but it can't enforce them
AFAIK.
Is that going to be maintanable in the long run?
An alternative would be to consistently run each and every build in
its own isolated docker container, but
a) that's not something I can setup overnight
b) we'd need to use more complex build scripts, for example the nice
Maven and Gradle integrations with the Jenkins build configuration
would be unusable.
We're having quite a list of services; even ignoring the OGM exotic
databases we have at least:
- Byteman
- JGroups
- Arquillian
- WildFly
- ActiveMQ (JMS tests in Search)
- ... ?
To fight the urgent need, I'm going to prevent parallelism of any
build. Let's hope ORM's master doesn't get stuck, as everything else
would be blocked. I really hope this measure stays as temporary as
possible :-/
-- Sanne
1 - https://hibernate.atlassian.net/browse/WEBSITE-178
2 - https://wiki.jenkins-ci.org/display/JENKINS/Port+Allocator+Plugin
10 years, 1 month
@ManyToOne + @Basic
by Steve Ebersole
There is a test currently failing with the new metamodel code. The mapping
that causes the problem has the following annotations:
@Id
@ManyToOne(...)
@JoinColumns(...)
@Basic(fetch=FetchType.LAZY)
Is it really legal to combine @ManyToOne and @Basic? Those seem "at odds".
My guess is that the legacy binding code simply did not validate for this.
Wdyt?
10 years, 1 month
Hakergarten session for Devoxx France
by Emmanuel Bernard
I will be at Devoxx France to help on a Hackergarten session. This is
basically some time where people come to contribute to a project,
hopefully being the start of a long relationship :)
I can mentor people around Hibernate Search and Hibernate OGM. Could you
tag some issues on JIRA as easily doable in 1 to 2 hours.
Emmanuel
10 years, 1 month
Permissions and teams update; teaser on the Docker work
by Sanne Grinovero
I've created a new team for the Hibernate HQL parser project, as there
is some overlap with other projects beyond the Hibernate OGM team.
Then added
- Adrian Nistor to the Hibernate organization (to the parser project)
- Everyone who was on OGM to the parser project
- Steve Ebersole to the parser project
- Paolo Antinori to the Hibernate organization (devops project)
Paolo is working on a Docker based testsuite for Hibernate OGM, and I
hope to reuse some of that for relational databases too. I'll let him
describe his work better when it's ready.
An article on these early experiments made it to DZone:
http://www.dzone.com/links/r/integration_testing_with_maven_and_docker.html
-- Sanne
10 years, 1 month
[OGM] Element collections stored embedded in entity
by Gunnar Morling
Hi,
I just did some testing around @ElementCollection using MongoDB. A
collection of a basic type results in the following persistent format of
the embedding entity:
{
"_id": "17457a47-abfc-4fb7-955e-17acb0b49808",
"nicknames": [
{ "nicknames": "idrA" },
{ "nicknames": "day[9]" }
]
}
Is there any reason why we don't use this instead:
{
"_id": "17457a47-abfc-4fb7-955e-17acb0b49808",
"nicknames": [
"idrA",
"day[9]"
]
}
For non-basic, embeddable types it looks like this:
{
"_id": "17457a47-abfc-4fb7-955e-17acb0b49808",
"homeAddress": [
{
"homeAddress.collection&&element.city": "Paris",
"homeAddress.collection&&element.country": "France",
"homeAddress.collection&&element.street1": "1 avenue des
Champs Elysees",
"homeAddress.collection&&element.street2": null,
"postal_code": "75007"
}
]
}
Is this "collection&&element" style intended, or could we use the simple
property name as keys here ("postal_code" is specified explicitly via
@Column)?
I can file issues in JIRA (and take a look at some point), but wanted to be
sure I'm not missing something here.
Thanks,
--Gunnar
10 years, 1 month
Possibly interesting use of Jandex
by Steve Ebersole
As I move through the metamodel code, I try to keep an eye on things we
want to do eventually and where/how they might fit in the new mapping
processing and binding code.
One of the changes we are going through is the move to Jandex. Mainly we
are using Jandex for its "annotation indexing" capabilities. But Jandex
also has some limited ability to query class relationships, mainly in terms
of hierarchies. For example, Jandex lets you ask for all classes that are
extensions of a given class or for all classes that are implementations of
a given interface.
This last part combined in my head with a previous discussion we have had
with regard to "dynamic models". The idea was to support generic contracts
on the Hibernate Session interface. The main difficulty there being in how
@Proxy is handled internally versus on the API. Given an entity like:
@Entity
@Proxy(proxyClass=Employee.class)
class EmployeeImpl implements Employee {
...
}
the problem is the attempt to type the return of, e.g., Session#get based
on the Class parameter passed in because atm you'd have to pass in
EmployeeImpl.. but the result would not necessarily be castable to
EmployeeImpl.
The "simple" solution for this is to allow some form of call where the
Employee interface is passed in rather than the EmployeeImpl class.
Internally this most likely means a cross reference from Employee
->Persister just like we already do for EmployeeImpl->Persister. We'd want
to be VERY sure there is only one impl per interface in this model. Jandex
can help there. Not sure how to best handle "persistent inheritance" and
especially middle types. I think the difference
between org.jboss.jandex.IndexView#getKnownDirectImplementors
and org.jboss.jandex.IndexView#getAllKnownImplementors can be leveraged
here.
Then we had expanded the previous discussion to look at the more general
case... interface based models. Imo, the best way to map the above model
would be:
@Entity
interface Employee {
...
}
Yes, this deviates from JPA which explicitly says that only classes can be
annotated. The question is whether we think its worthy of a "vendor
extension".
This mapping could be interpreted in one of 2 ways:
1) We assume that there is a class that implements this interface
(EmployeeImpl) and use that as the concrete class. A lot of the discussion
previously was how to "bind" the interface and the concrete class. Again,
Jandex can help us there by telling us about "known implementors". More
than one would be an error I guess.
2) We'd dynamically generate a class to back this. This generated class
can contain many of the performance tweaks we've been developing via
bytecode extensions (inline dirty-checking, "entity entry" info, etc).
Note that many of the "Jandex can help us" statements make an assumption
that Jandex knows about all the classes we are interested in. In the
WildFly/Jipijapa deployment case that is not a problem. In other scenarios
it is something to be mindful of since we'd need to properly feed the
indexer (which is a concern anyway outside of this discussion).
10 years, 1 month
Storing values at the session level
by Gunnar Morling
Hi,
I'm looking into ways for reducing the number of datastore roundtrips in
OGM [1].
One idea is to fetch associations embedded within entity documents (e.g. in
MongoDB) when loading such document. We'd "remember" the entity document
and could later on retrieve the association from it without going to the
store a second time.
The problem is the "remembering" part. There is no session-scoped storage
facility as of today which I could use. I contemplated making OgmSession
deal with this, but I can't access that from persisters etc. Instead I'm
seeing the wrapped SessionImpl (to which OgmSession delegates for many
operations) and I couldn't find a way to reach the wrapping OgmSession
instance.
Now I noticed the concept of "SessionOwner" in SessionImpl and am wondering
whether I could make use of this. When creating the SessionImpl, I could
pass the OgmSession as owner and have it maintain a session-scoped storage.
Unfortunately there is no getter for the session owner on
SessionFactoryImplementor, though.
Would it be feasible to add this getter and thus make a session's owner
accessible? Or is there any other (better) way to achieve what I described?
Many thanks,
--Gunnar
[1] https://hibernate.atlassian.net/browse/OGM-469
10 years, 1 month
