Re: [hibernate-dev] Annotations patch for column read/write expressions (HHH-272)
I think we should simply use a @o.h.a.Columns annotation to embed
@o.h.a.Column annotations and place them on the same property the
@j.p.Column is described.
@Column(name="foo")
@o.h.a.Column(appliesTo="foo", wrap="nsacrypt(?)")
public String getPassword() { ... }
@AttributeOverride(name="street1", colu...@column(name="foo"))
@o.h.a.Column(appliesTo="foo", wrap="nsacrypt(?)")
public Address getHome() {};
We have two solutions:
- reuse @o.h.a.Columns and add
o.h.a.Column[] specialize() default {};
mark columns as default {}; and deal with that in the code (today
someone mapping @Columns() would not work so well).
- create an entirely new annotation @o.h.a.SpecializedColumns
specialized is too long though, a smaller name would greatly help
On 23 sept. 09, at 18:40, Rob Hasselbaum wrote:
> I'm working on an patch to expose HHH-272 functionality (custom
> column read and write expressions).in Annotations. At Steve and
> Emmanuel's request, I'm doing this by creating a new @o.h.a.Column
> annotation to supplement the @javax.persistence.Column annotation,
> similar to what's in place today for @Table. This will allow for
> future extension beyond this one use case, eventually.
>
> It's getting a bit dicey, though, because of the variety of places
> @j.p.Column can show up--for example, inside @AttributeOverride and
> @Columns. The question is how best to embed the companion
> @o.h.a.Column instances in these contexts. Create a
> @o.h.a.AttributeOverride and @o.h.a.AttributeOverrides? A totally
> separate grouping mechanism? It's a little easier with @Columns
> because that's already in the org.hibernate namespace hierarchy, so
> it can be modified. Thoughts?
>
> -Rob
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Fwd: [infinispan-dev] Wiki up on Querying
Forgot to send this out to Hibernate Dev as well. Begin forwarded message: From: Navin Surtani Date: 24 September 2009 15:10:34 BST To: infinispan -Dev List Subject: [infinispan-dev] Wiki up on Querying Reply-To: infinispan -Dev List Heya guys, Just to let you know the wiki article on Querying is now up. http://www.jboss.org/community/wiki/QueryingInfinispan Also, have a read at the blog: - http://infinispan.blogspot.com/2009/09/infinispan-query-breaks-into-400cr1_23.html Navin Surtani Intern Infinispan Intern JBoss Cache Searchable ___ infinispan-dev mailing list infinispan-...@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev Navin Surtani Intern Infinispan Intern JBoss Cache Searchable ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [infinispan-dev] Hibernate 3.5.0.Beta-1 released
Try typing "hibernate default cache provider" into Google. ;-) Note that the (official?) docs [1] state: "Note that versions prior to 3.2 use EhCache as the default cache provider." So perhaps most of the hits refer to old versions of Hibernate. And if the reason for removing a default altogether is to pass a TCK and multiple inits, we can have a chat about this to see how we can make this work (Infinispan has a concept of a default cache, which "just works" and is always available, if that helps with multiple inits). All the same, it would be good to have some sort of preference expressed in the docs even if you don't want to ship a default, but that's up to you guys. Cheers Manik [1] http://docs.jboss.org/hibernate/stable/core/reference/en-US/html/performance.html#performance-cache On 9 Sep 2009, at 18:04, Emmanuel Bernard wrote: > Let me say it for the third time (complementing Steve's first two). > There is no default cache provider, a user has to chose one. One of > the reasons for this move was that the JPA TCK was having issues with > cache systems and multiple initializations. > > On 9 sept. 09, at 18:58, Steve Ebersole wrote: > >> Again, there is no default cache provider. Users must decide which >> to >> use. >> >> On Wed, 2009-09-09 at 11:42 -0500, Sanne Grinovero wrote: >>> I'd like to see Infinispan as default cache provider, AFAIK ehcache >>> is >>> the default now. >>> >>> IMHO the default is to some extend a recommendation to the users, at >>> least that's >>> how I perceived it when I was new to hibernate: "if they have chosen >>> it, it must be good". >>> >>> It would need however to be able to work at least in single-vm mode >>> without configuration, >>> to keep it as simple as possible for beginners. >>> >>> 2009/9/9 Galder Zamarreno : Steve, taking in account that at least in the community version you ship a few different cache providers (correct me if I'm wrong), what about putting something in the Hibernate docs where you recommend using Infinispan? i.e. "Infinispan is the recommended 2LC provider" On 08/31/2009 06:02 PM, Steve Ebersole wrote: > We do not make any cache integration the default. There are too > many > variables that have to come in to play... > > On Mon, 2009-08-31 at 17:55 +0200, Galder Zamarreno wrote: >> Bugger, this was released hours before I committed the >> Infinispan cache >> provider :( >> >> Steve, let's catch up before next 3.5 release in order to figure >> out >> what's needed to make Infinispan the default cache provider. Do >> you make >> such decision based on any performance test or the configuration >> itself? >> My aim is to make Infinispan the best 2nd level cache provider >> out there. >> >> On 08/21/2009 06:43 PM, Steve Ebersole wrote: >>> Hibernate 3.5.0.Beta-1 has been released. Please see >>> http://in.relation.to/12153.lace for details. >>> >> -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-...@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev >> -- >> Steve Ebersole >> Hibernate.org >> >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > ___ > infinispan-dev mailing list > infinispan-...@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani ma...@jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [infinispan-dev] Benchmarking 2nd level cache providers?
Do we have a JIRA for this? Are we tracking this somewhere? On 2 Sep 2009, at 14:25, Steve Ebersole wrote: > The best bet for something like this is a separate project which pulls > in the proper hibernate dependencies. Then we can talk with Juca > about > getting them set up on a scheduled run. > > However, if you want to have the configuration varied for different > runs, I suggest you wait until after the discussions with the Maven > developers to address the numerous specific issues we have encountered > with Maven. This is exactly one of the issues "on the docket". We > have > issues with this "varied config" piece in the core/testsuite module. > > On Wed, 2009-09-02 at 06:20 -0500, Sanne Grinovero wrote: >> Totally agree with this, it would be useful also to benchmark other >> parts of Hibernate (not just the cache) >> and as general regression test. >> Also with Hibernate Search I have some "private tests" which are very >> time consuming (an hour or so) which I can't >> commit on trunk as unit tests; I'd like to have them somewhere, maybe >> regularly executed by Continuous Integration >> (too much work for existing Hudson?). >> >> Sanne >> >> 2009/9/1 Galder Zamarreno : >>> >>> >>> On 08/26/2009 05:48 PM, Mircea Markus wrote: Can't we write a plugin for the CacheBenchmark fwk? >>> >>> We could potentially do so but we'd be missing loads of things and >>> we'd >>> have to spend a fair bit of time replicating the way Hibernate >>> uses the >>> cache which is not straightforward by any means. Take in account >>> as well >>> that there're several caches and cache usages involved here: entity, >>> collection, query and timestamps and each has a different usage >>> pattern. >>> Bottom line: I don't think trying to emulate this is worth the >>> effort. >>> >>> What is needed here is a Hibernate/JPA load/perf test environment >>> where >>> the most common Hibernate usage patterns are exercised and then >>> you swap >>> 2nd level cache providers. This is really what counts to the >>> users: how >>> quickly I can persist N entities, how quick I can read N times an >>> entity >>> that I've just persisted, how fast I can execute same query N >>> times...etc, these are the use cases where the cache provider must >>> show off. >>> >>> I haven't heard anything from the HB team wrt to this, so I assume >>> they >>> don't have anything like this. >>> On Aug 19, 2009, at 1:14 PM, Galder Zamarreno wrote: > While talking to Manik online, the topic of 2nd level cache > benchmarking > came up and was wondering if there's a way to benchmark > different 2nd > level cache providers in Hibernate? > > Cheers, > -- > Galder Zamarreño > Sr. Software Engineer > Infinispan, JBoss Cache > ___ > infinispan-dev mailing list > infinispan-...@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> -- >>> Galder Zamarreño >>> Sr. Software Engineer >>> Infinispan, JBoss Cache >>> ___ >>> infinispan-dev mailing list >>> infinispan-...@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >> >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > -- > Steve Ebersole > Hibernate.org > > ___ > infinispan-dev mailing list > infinispan-...@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani ma...@jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [infinispan-dev] Feedback on Infinispan patch
Minorly off topic, but rather than working with patches, do we want
this Directory impl in source control somewhere?
Being dependent on LGPL, it won't be accepted into Lucene's contribs.
If it doesn't depend on any Hibernate Search code, I could host it in
Infinispan's SVN repo...
On 23 Sep 2009, at 13:58, Łukasz Moreń wrote:
I agree that Infinispan case is not much different from
RamDirectory. The major difference is that in RD (also
FileDirectory) changes are not batched like in ID. If I do not wrap
changes in InfinispanDirectory(simple remove tx.begin() from obtain
() method and tx.commit() from release() in InfinispanLock), and
immediately commit every change made by IW it works well. Hovewer it
makes indexing really slower, because of frequent replication to
other nodes.
Sanne it's good remark that IW commit is kind of flush.
I've attached patch with InfinispanDirectory, failing test is
testDirectoryWithMultipleThreads in InfinispanDirectoryTest class.
It fails randomly. I think problem is Infinispan commit on
lockRelease() in org.apache.lucene.index.IndexWriter (line 1658) is
after IW commit() (line 1654).
Is it because, the IndexWriter only clean files if no indexReaders
are reading them (how would that be detected)?
It can happen if IndexWriter clean file, and IndexReader try to
access that cleaned file.
2009/9/23 Sanne Grinovero
I agree It should work the same way; The IndexWriter cleans files
whenever it likes to, it doesn't try to detect readers, and this
shouldn't have any effect on the working of readers.
The IndexReader opens the "SegmentsInfo" first, and immediately
after** gets a reference to the segments listed in this SegmentsInfo.
No IndexWriter will ever change an existing segment, only add new
files or eventually delete old ones (segments merge,optimize).
The deletion of segments is the interesting subject: when using Files
it uses "delete at last close", which works because the IR needing it
have it opened already**; when using the RAMDirectory they have a
reference preventing garbage collection.
( the two "**" are assuming the same event occurred correctly,
otherwise an exception is thrown at opening)
When using Infinispan it shouldn't be much different than the
RAMDirectory? so even if the needed segment is deleted, the IR holds a
reference to the Java object locally since it was opened.
Łukcasz, do you have some failing test?
Sanne
2009/9/23 Emmanuel Bernard :
> Conceptually I don't understand why it does work in a pure file
system
> directory (ie IndexReader can go and process queries with the
IndexWriter
> goes about its business) and not when using Infinispan.
> Is it because, the IndexWriter only clean files if no indexReaders
are
> reading them (how would that be detected)?
> On 22 sept. 09, at 20:46, Łukasz Moreń wrote:
>
> I need to provide this same lifecycle for IndexWriter as for
Infinispan tx -
> IW is created: tx is started, IW is commited: tx is commited. It
assures
> that IndexReader doesn't read old data from directory.
> Infinispan transaction can be started when IW acquires the lock,
but its
> commit on IW lock release, as it is done so far, causes a problem:
>
> index writer close {
> index writer commit(); //changes are visible for IndexReaders
>
>//Index reader starts reading here, i.e. tries to access
file "A"
>
> index writer lockRelease(); //changes in Infinispan directory are
> commited, file "A" was removed, IndexReader cannot find it and
crashes
> }
>
> I think Infinispan tx have to be commited just before IW commit,
and the
> problem is where to put in code.
>
> W dniu 22 września 2009 18:24 użytkownik Emmanuel Bernard
> napisał:
>>
>> Can you explain in more details what is going on.
>> Aside from that Workspace has been Sanne's baby lately so he will
be the
>> best to see what design will work in HSearch. That being said, I
don't like
>> the idea of subclassing / overriding very much. In my experience,
it has
>> lead to more bad and unmaintainable code than anything else.
>> On 22 sept. 09, at 02:16, Łukasz Moreń wrote:
>>
>> Hi,
>>
>> Thanks for explanation.
>> Maybe better I will concentrate on the first release and postpone
>> distributed writing.
>>
>> There is already LockStrategy that uses Infinispan. With using it
I was
>> wrapping changes made by IndexWriter in Infinispan transaction,
because of
>> performance reasons -
>> on lock obtaining transaction was started, on lock release
transaction was
>> commited. Hovewer Ispn transaction commit on lock release is not
good idea
>> since IndexWriter calls index commit before lock is released(and
ispn
>> transaction is committed).
>> I was thinking to override Workspace class and getIndexWriter(start
>> infinispan tx), commitIndexWriter (commit tx) methods to wrap
IndexWrite
>> lifecycle, but this needs few other changes. Some other ideas?
>>
>> Cheers,
>> Lukasz
>>
>> 2009/9/21 Sanne Grinover
Re: [hibernate-dev] [infinispan-dev] Feedback on Infinispan patch
+1
On 24 sept. 09, at 17:49, Manik Surtani wrote:
Minorly off topic, but rather than working with patches, do we want
this Directory impl in source control somewhere?
Being dependent on LGPL, it won't be accepted into Lucene's
contribs. If it doesn't depend on any Hibernate Search code, I
could host it in Infinispan's SVN repo...
On 23 Sep 2009, at 13:58, Łukasz Moreń wrote:
I agree that Infinispan case is not much different from
RamDirectory. The major difference is that in RD (also
FileDirectory) changes are not batched like in ID. If I do not wrap
changes in InfinispanDirectory(simple remove tx.begin() from
obtain() method and tx.commit() from release() in InfinispanLock),
and immediately commit every change made by IW it works well.
Hovewer it makes indexing really slower, because of frequent
replication to other nodes.
Sanne it's good remark that IW commit is kind of flush.
I've attached patch with InfinispanDirectory, failing test is
testDirectoryWithMultipleThreads in InfinispanDirectoryTest class.
It fails randomly. I think problem is Infinispan commit on
lockRelease() in org.apache.lucene.index.IndexWriter (line 1658) is
after IW commit() (line 1654).
Is it because, the IndexWriter only clean files if no indexReaders
are reading them (how would that be detected)?
It can happen if IndexWriter clean file, and IndexReader try to
access that cleaned file.
2009/9/23 Sanne Grinovero
I agree It should work the same way; The IndexWriter cleans files
whenever it likes to, it doesn't try to detect readers, and this
shouldn't have any effect on the working of readers.
The IndexReader opens the "SegmentsInfo" first, and immediately
after** gets a reference to the segments listed in this SegmentsInfo.
No IndexWriter will ever change an existing segment, only add new
files or eventually delete old ones (segments merge,optimize).
The deletion of segments is the interesting subject: when using Files
it uses "delete at last close", which works because the IR needing it
have it opened already**; when using the RAMDirectory they have a
reference preventing garbage collection.
( the two "**" are assuming the same event occurred correctly,
otherwise an exception is thrown at opening)
When using Infinispan it shouldn't be much different than the
RAMDirectory? so even if the needed segment is deleted, the IR
holds a
reference to the Java object locally since it was opened.
Łukcasz, do you have some failing test?
Sanne
2009/9/23 Emmanuel Bernard :
> Conceptually I don't understand why it does work in a pure file
system
> directory (ie IndexReader can go and process queries with the
IndexWriter
> goes about its business) and not when using Infinispan.
> Is it because, the IndexWriter only clean files if no
indexReaders are
> reading them (how would that be detected)?
> On 22 sept. 09, at 20:46, Łukasz Moreń wrote:
>
> I need to provide this same lifecycle for IndexWriter as for
Infinispan tx -
> IW is created: tx is started, IW is commited: tx is commited. It
assures
> that IndexReader doesn't read old data from directory.
> Infinispan transaction can be started when IW acquires the lock,
but its
> commit on IW lock release, as it is done so far, causes a problem:
>
> index writer close {
> index writer commit(); //changes are visible for IndexReaders
>
>//Index reader starts reading here, i.e. tries to access
file "A"
>
> index writer lockRelease(); //changes in Infinispan directory are
> commited, file "A" was removed, IndexReader cannot find it and
crashes
> }
>
> I think Infinispan tx have to be commited just before IW commit,
and the
> problem is where to put in code.
>
> W dniu 22 września 2009 18:24 użytkownik Emmanuel Bernard
> napisał:
>>
>> Can you explain in more details what is going on.
>> Aside from that Workspace has been Sanne's baby lately so he
will be the
>> best to see what design will work in HSearch. That being said, I
don't like
>> the idea of subclassing / overriding very much. In my
experience, it has
>> lead to more bad and unmaintainable code than anything else.
>> On 22 sept. 09, at 02:16, Łukasz Moreń wrote:
>>
>> Hi,
>>
>> Thanks for explanation.
>> Maybe better I will concentrate on the first release and postpone
>> distributed writing.
>>
>> There is already LockStrategy that uses Infinispan. With using
it I was
>> wrapping changes made by IndexWriter in Infinispan transaction,
because of
>> performance reasons -
>> on lock obtaining transaction was started, on lock release
transaction was
>> commited. Hovewer Ispn transaction commit on lock release is not
good idea
>> since IndexWriter calls index commit before lock is released(and
ispn
>> transaction is committed).
>> I was thinking to override Workspace class and
getIndexWriter(start
>> infinispan tx), commitIndexWriter (commit tx) methods to wrap
IndexWrite
>> lifecycle, but this needs few other changes. Some other ide
[hibernate-dev] Patch for HHH-2308: Adjusting the Outer Join Predicate using Criteria Query
Hello,
I've submitted a patch which updates Scott Van Wart's effort with unit tests
and documentation changes (en-US) for HHH-2308. This patch allows users to add
Criterion to Criteria aliasing similar to the WITH clause in hql.
List result = session.createCriteria( Student.class )
.createAlias( "preferredCourse", "pc", Criteria.LEFT_JOIN,
Restrictions.eq("pc.courseCode", "HIB-A") )
.setProjection( Property.forName("pc.courseCode") )
.addOrder(Order.asc("pc.courseCode"))
.list();
This is useful when sorting large and or complex data inside the database when
you intend to only retrieve X number of records from the result-set.
Without this patch we are forced to perform the same query as follows:
1. Query without join constraint and store results.
2. Query with an inner join and store results.
3. Manually sort in memory with java.
This effectively doubles the workload on the database as the queries are
complex even without this join. It also causes some concern as to memory
constraints because the full number of allowable data elements must be loaded
twice. I'd love to be able to use HQL to solve this problem, however the
search is very dynamic and the Criteria interface has helped to solve the
problem much more elegantly.
The file hibernate-outer-join-criteria-trunk.diff attached to this defect is
the latest example on trunk (3.5)
Thanks,
Craig Christophel
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
