maven-test-ext-plugin !?
by Hardy Ferentschik
Speaking of plugins, what does the maven-test-ext-plugin do for us and why
is it needed in
the annotations module? The build seems to work fine even w/o.
--Hardy
16 years
3.5.0-Beta-3 has different behaviour on commit as 3.5.0-Beta-2, is this intended?
by Guenther Demetz
-until 3.5.0-Beta-2 a ConstraintViolationException during commit caused
an implicite rollback and the exception was wrapped into a
javax.persistence.RollbackException
-now with 3.5.0-Beta-3 the same ConstraintViolationException during
commit is wrapped into a javax.persistence.PersistenceException without
implicite rollback
Is this a wanted behavior change?
If yes, where it is documented?
best regards
G.D.
16 years
HSEARCH Dynamic proxy for FullTextSessionImpl, FTEMImpl
by Emmanuel Bernard
Guys,
I am sick of HSearch being broken every time Core adds a new method to Session / SessionImplementor and the like.
I am seriously thinking about providing a dynamic proxy implementing FTSession etc and will try and prototype it.
Any opinion?
16 years
Collaborative Development for Hibernate
by Eike Starkmann
Hi,
I am working in the Institute of Computer Science at the Free University
of Berlin where we are creating ways to improve the process of writing
software, especially for Free/Open Source Software developers.
Our institute develops Saros, an open source Eclipse plug-in that allows
two or more developers to work together in real-time developing code,
training newcomers, or performing peer reviews.
It is similar to Gobby, SubEthaEdit or Google Docs but focuses on
programming in Eclipse.
As part of my masters thesis I would like to assess how useful Saros is
when developing Free/Open Source Software. I already was in contact with
other projects and got some good response.
It is believed that Saros is particularly well suited to the following
development scenarios:
* an arbitrary number of developers working together over a network on a
common project
* distributed pair programming, with an author and an observer who are
geographically dispersed
* transferring knowledge between developers and introducing new people
to the project
* joint code reviews
* collaborative development where developers are aware of each other and
wish to switch easily between working together or independently
If you are interested, I would offer you to join Hibernate for a while
to give you support while working with Saros. What do you think?
Kind regards, Eike Starkmann
For more information:
Website: https://www.inf.fu-berlin.de/w/SE/DPP
Update Site: http://dpp.sf.net/update
Saros @ SF: http://sourceforge.net/projects/dpp/
Programming Languages Supported by Saros :
https://www.inf.fu-berlin.de/w/SE/DPPCompatiblePlugin
--
Eike Starkmann
This message is part of my Master thesis research. Feel free to contact
my advisors in case of inappropriate behavior on my side:
christopher.oezbek(a)fu-berlin.de and stephan.salinger(a)fu-berlin.de
16 years
HQL + numeric literal typing
by Steve Ebersole
I need to add a way to further define the type of numeric literals.
Currently HQL supports the use of the 'F', 'D' and 'L' suffixes as
defined by Java to demarcate floats, doubles and longs respectively. I
find myself the need to do the same with BigInteger and BigDecimal.
I see two options:
1) 2 new suffixes ( 'BI' and 'BD'? )
2) new escape syntax ( {as BigInteger 10000000} ? )
As a side note, I could in fact just use the CAST function as HQL does
support notion like CAST( 10000000 AS java.math.BigDecimal ). However
that results in a SQL cast as well, and we get into potential issues
with "bad dialect setup". Ideally I am just looking for a way to
identify the exact java type to use.
As an example of why this is important... The issue I ran into deals
with the JPA rules for determining query return types. Take a
multiplication: JPA says that a multiplication that involves a
BigInteger as one of its operands should return a BigInteger. So
consider "select some.attributePath * 10000000 ...". If
'some.attributePath' is defined as Integer, this multiplication will
result in a Integer value because the '10000000' literal will also be
interpreted as Integer.
This can also be useful for parameters as well (although this whole
issue is generally related to select clauses and many databases have
well defined restrictions on using parameters in select, at least
without the explicit CAST so they know what types to expect).
So as far as an escape syntax, I guess the main question is how
generally useful this might be in other clauses and across other data
types.
Anyone else run across similar needs that would impact here?
--
Steve Ebersole <steve(a)hibernate.org>
Hibernate.org
16 years
difficulties in upgrading to Lucene 3
by Sanne Grinovero
Hello all,
I've been thinking about the strategy to upgrade to Lucene 3;
Ignoring new features at the moment, the main issues in migration:
1- Store.COMPRESS not supported anymore
2- Some Analyzers and the QueryParser require an additional
constructor parameter
3- DocIdSet interface (used in filters) changed - changed even in
Lucene 2.9.x, making step-by-step migration harder
While point 2 is not a great problem (I'm having a patch ready);
points 1 and 3 are connected: DocIdSet must be solved as soon as we
move to 2.9, while 2.9 is a requirement to implement COMPRESS in a
different way if we choose to:
It appears we can't maintain binary index compatibility, but
supporting the feature is an option.
Lucene 3 will transparently decompress an old-style compressed field
when reading it and it will even decompress all fields during
optimization, effectively transforming the index to the new format.
If we want to still support the contract of
org.hibernate.search.annotations.Store.COMPRESS we will have to
compress ourself the field, possibly using a pluggable strategy;
assuming the use of org.apache.lucene.document.CompressionTools as
default implementation we can provide a backwards compatible-API but
the resulting index is going to have a different format.
A future improvement could be to use any external
compression/decompression function (user provided implementation), any
idea where? Maybe replace the Store enum with an interface?
What should I do to solve HSEARCH-425 ?
The options I've considered so far:
A) Deprecate the Store.COMPRESS, without providing an alternative
B) Change implementation to make use of Lucene's CompressionTools
CompressionTools only exist since Lucene 2.9, so an upgrade is
mandatory but other features are going to break, like filters
(org.hibernate.search.filter.AndDocIdSet needs to implement an updated
interface)
So basically I'll need a branch, break some tests temporarily, or
provide a single huge patch refactoring some features and tests at
same time :-/
An alternative to branching would be to solve the Compress issue
later, and focus on the build breaking changes first; in practice this
would break the compression feature until it's fixed, but this
shouldn't be a great problem as it going to change anyway...
WDYT?
I'm working on the new DocIdSet, even that will be a considerable change.
Cheers,
Sanne
16 years
Reelase for
by Emmanuel Bernard
Steve,
Do you think there is enough material / bug fix to cut another beta for inclusion in AS 6 M2?
Something like a 2 weeks target.
On my side that would make sense to push the discrete but new mapping / bug fixes out for trial. It also helps Hibernate Search development (on Core snapshot ATM).
Emmanuel
Begin forwarded message:
> From: Brian Stansberry <brian.stansberry(a)redhat.com>
> Date: 6 janvier 2010 17:38:37 HNEC
> To: jboss-development(a)lists.jboss.org
> Subject: Re: [jboss-dev] Further profling: Where should I focus?
> Reply-To: "JBoss.org development list" <jboss-development(a)lists.jboss.org>
>>
>>
>> Any ETA on VFS3 being done and integrated with AS 6?
>>
>
> My guesstimate is very early in the M3 cycle (i.e. as soon as we open
> trunk to commits after M2). So mid-February.
>
> It's tempting to try for M2, but there's only 3.5 weeks left before
> component integration freeze, this is a big disruptive change and there
> are a couple issues to resolve:
>
> 1) Detecting modifications of exploded deployments:
> http://community.jboss.org/thread/146098
>
> 2) This caching discussion, which IMHO should continue. It's legit to
> think again about what the intended use cases are for VFS and see if its
> API can be adjusted to more effectively handle those use cases.
>
> The MC team is going to be putting out a 2.2 alpha release soon; while
> that's being integrated in the AS and issues resolved over the next week
> it makes little sense to try and start pushing in VFS3. So let's use
> that time to resolve the modification detection issue and discuss a bit
> more about caching. By the end of next week we should have a clearer
> picture as to whether trying for M2 is feasible.
>
> --
> Brian Stansberry
> Lead, AS Clustering
> JBoss by Red Hat
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
16 years
criteria + SUM
by Steve Ebersole
My understanding is that the return types for aggregation function in
criteria queries should follow the same rules as defined for JPAQL. So
first, is that a correct understanding?
The confusion is the type signatures of the builder methods, espcially
the ones that "change" based on the argument types. SUM, for example,
says the following in the JPAQL section:
<quote>
SUM returns Long when applied to state fields of integral types (other
than BigInteger); Double
when applied to state fields of floating point types; BigInteger when
applied to state fields
of type BigInteger; and BigDecimal when applied to state fields of type
BigDecimal.
</quote>
So for a SUM of int or Integer fileds, JPAQL is clearly expecting back a
Long.
The CriteriaBuilder sum method, however, is defined as:
<N extends Number> Expression<N> sum(Expression<N> x);
Which implies that when applied to an int or Integer field/expression
should return an Integer. Yes, I realize the last spec version added
the sumAsDouble/sumAsLong methods, but that is still not really the same
as the JPAQL rules.
The TCK does explicitly have a test for this btw and we are currently
failing. *However* even the test notes show the confusion here as it
states:
<quote>
Execute a query which contains the aggregate function SUM.
SUM returns Long when applied to state-fields of integral types.
</quote>
Unfortunately as soon as it says that is goes off and actually asserts
the return is a Integer ;)
So I am trying to decide if this need be a challenge based on "alignment
with JPAQL rules", a challenge based on something else you might see or
an inconsistency JPA users will have to live with?
--
Steve Ebersole <steve(a)hibernate.org>
Hibernate.org
16 years
