Re: [hibernate-dev] Changelog file in Hibernate ORM

I like the changelog file too for a few reasons : - URLs do change. Say the URL to point to the changelog generation evolves in JIRA. - scrolling and CTRL+F is pretty good to find the info you are looking for. - I like self contained releases It is a manual step but we might be able to automati

Re: [hibernate-dev] Is @SecondaryTable required when a join table is specified?

I don't think you are right Gail. You can use secondary tables even if no association are involved. We happen to use the secondary table mechanism to map one to one + join table but that's an implementation detail of Hibernate ORM. On 1 mars 2013, at 20:49, Gail Badner wrote: > Actually, ther

Re: [hibernate-dev] [OGM] Ogm mass indexer, how to convert Tuple/EntityKey to Entity/Id?

The mass indexer does not work at the resultset level so mixing tuples and mass indexer seems wrong to me. Have you considered something like Iterator getAllTuplesFrom(String... tableNames); And then expose an Iterator (ie entities) to the mass indexer? I mean we could make it work with your

Re: [hibernate-dev] JPA 2.1 API compiled with JDK 7!?

JPA 2.1 users cannot portably use JDK 6 but if we can we could try and support it in our implementations. Best effort. On Mon 2013-02-25 19:17, Gunnar Morling wrote: > > 1) JPA 2.1 is part of EE 7 which requires SE 7 > > But couldn't JPA 2.1 be used in 1.6 SE environments? I guess there'd be > us

Re: [hibernate-dev] Loader redesign proposal

nice, I'll have a look. If I can squeeze a bit of OGM friendliness to the redesign, that would be a nice bonus. By the way, any reason to create a dedicated repo instead of a branch? I mistakenly imported your repo in my orm repo ;) Emmanuel On Mon 2013-02-25 13:19, Steve Ebersole wrote: > I bel

Re: [hibernate-dev] core built-in encryption

Irrespective of this discussion, a single salt value for all you entries is discouraged. It's better to have one salt value per entry. Some algorithms even embed the salt in the encrypted value itself so that everything is stored in a single column. In an ideal world, you would keep the salts in a

Re: [hibernate-dev] [OGM] Transactions in Neo4j datastore

Do you have an alternative in mind? My understanding is that if you write a Neo4J JtaPlatform, then the transaction will be started: - if the transaction is manually started by the wrapping code - if someone uses Session.beginTransaction() or EntityManager.getTransaction().begin() You wanted t

Re: [hibernate-dev] ValidationMode

Our impl allow multiple choices to be able to add ddl as an additional behavior as it (was) not defined in the spec. And indeed, auto uses the degraded mode and callback forced BV to be used and raise an exception if it is not present. I can see apps deciding for one or the other. Emmanuel On Fr

Re: [hibernate-dev] Loader redesign proposal

Oops, did reply instead of reply-all On 03/04/2013 07:23 AM, Steve Ebersole wrote: > > Personal preference I guess, but while developing major features I > find it easier to keep track of my ongoing work that way > > On Mar 4, 2013 7:02 AM, "Emmanuel Bernard" > wr

Re: [hibernate-dev] ValidationMode

My concern is not the additional option. My concern is the allowance of multiple selections. The only combo that ever even conceivably makes sense is "ddl" and "callback" together. But I am questioning how sensible it is really to have those 2 together. IMHO not much sense at all. So IMO we

Re: [hibernate-dev] ValidationMode

I don't follow you. It seems to make sense to me to have ddl and callback. It says validate entities on CRUD events, apply database generation in accordance to the constraints and raise an exception if BV is not present in the CP. On Mon 2013-03-04 7:36, Steve Ebersole wrote: > My concern is no

Re: [hibernate-dev] ValidationMode

Partially. What it also says is too perform double checking (callback and db constraints) when BV is present. I guess the reason you want to allow both is because we do not (and really can not) convert all validations to db contraints. My point is just that Set seems total overkill when there

Re: [hibernate-dev] Loader redesign proposal

Btw, I should point out that I do also have a hibernate-orm branch now since Friday when I started working on getting that code integrated into orm. That's because at this point I am happy enough with the walking and LoadPlan building code as far as it goes (eyes still welcome). Later today I

Re: [hibernate-dev] [OGM] Ogm mass indexer, how to convert Tuple/EntityKey to Entity/Id?

The Hibernate Search / ORM approach does iterate on the primary keys to get a consistent snapshot of the state to be reindexed, but subsequent phases avoid the "iterator" approach as it makes parallel execution very hard. With OGM/Infinispan I think the natural solution is to use Map/Reduce, and t

Re: [hibernate-dev] Changelog file in Hibernate ORM

I always maintain it in the 4.1/4.2 branches, but we admittedly forget to sync it in master. Up to you guys. Brett Meyer Red Hat Software Engineer, Hibernate +1 260.349.5732 - Original Message - From: "Steve Ebersole" To: "Sanne Grinovero" Cc: "Hibernate" Sent: Sunday, March 3, 2013

Re: [hibernate-dev] Changelog file in Hibernate ORM

+1 for keeping the changelog file. I also like the self-contained nature of release bundles with such a file, as this might come in handy when working offline etc. --Gunnar 2013/3/4 Brett Meyer > I always maintain it in the 4.1/4.2 branches, but we admittedly forget to > sync it in master. U

Re: [hibernate-dev] Changelog file in Hibernate ORM

I'd vote for continuing to maintain it as well. But I wonder if we ought to start truncating the back side of it. 10+ years is an awful lot of release/fix history and I doubt anyone seriously cares about about more that 5 years back (or less). Or maybe partitioned changelog files (1.0 versus

Re: [hibernate-dev] Changelog file in Hibernate ORM

For the record, -1 from me, but I guess I am already overruled. --Hardy On 4 Jan 2013, at 3:44 PM, Steve Ebersole wrote: > I'd vote for continuing to maintain it as well. But I wonder if we > ought to start truncating the back side of it. 10+ years is an awful > lot of release/fix history

Re: [hibernate-dev] ValidationMode

Applying validation at both levels has a few benefits: - DDL means that constraints are also applied to non Java apps or even third party apps not using Bean Validation - applying the constraint during the CRUD events provides more contextual exception reports, better than what we can do by co

Re: [hibernate-dev] [OGM] Ogm mass indexer, how to convert Tuple/EntityKey to Entity/Id?

I already gave what I knew on how to load an entity from a tuple (which isn't much) but we can try and dig together. Something I thought about is that ORM probably has a mechanism to load an entity from a resultset via the query parser. And that probably looks also like the second half of OgmLoader

Re: [hibernate-dev] Loader redesign proposal

Yes that'd be easier. For some reason, I cannot make gradle and IntelliJ play nice with your prototype, so I have red all over the place. On Mon 2013-03-04 8:05, Steve Ebersole wrote: > Btw, I should point out that I do also have a hibernate-orm branch > now since Friday when I started working o

Re: [hibernate-dev] ValidationMode

persistence provider portability. On Mon 04 Mar 2013 09:57:29 AM CST, Emmanuel Bernard wrote: > Applying validation at both levels has a few benefits: > > - DDL means that constraints are also applied to non Java apps or even >third party apps not using Bean Validation > - applying the constra

Re: [hibernate-dev] [OGM] Ogm mass indexer, how to convert Tuple/EntityKey to Entity/Id?

On 4 March 2013 16:20, Emmanuel Bernard wrote: > I already gave what I knew on how to load an entity from a tuple (which > isn't much) but we can try and dig together. Something I thought about > is that ORM probably has a mechanism to load an entity from a resultset > via the query parser. And th

Re: [hibernate-dev] Changelog file in Hibernate ORM

Depends what you mean "sync it in master". Its not like you should be cherry-picking changelog changes from other branches to master. But, you should be collecting the changes from Jira putting them into the changelog on the indicated branch(es). Currently, that means anything marked jpa21 sh

Re: [hibernate-dev] [OGM] Ogm mass indexer, how to convert Tuple/EntityKey to Entity/Id?

On 4 mars 2013, at 17:39, Sanne Grinovero wrote: > On 4 March 2013 16:20, Emmanuel Bernard wrote: >> I already gave what I knew on how to load an entity from a tuple (which >> isn't much) but we can try and dig together. Something I thought about >> is that ORM probably has a mechanism to load

Re: [hibernate-dev] [OGM] Ogm mass indexer, how to convert Tuple/EntityKey to Entity/Id?

We finished this discussion on IRC, in case someone else was interested: hum I forgot the first step.. transformation from entry into entity updated emmanuel, the "hidrate" step is what DavideD is bashing is head against, but let's assume he finds a workaround and we focus on the pattern as fir

Re: [hibernate-dev] [OGM] Ogm mass indexer, how to convert Tuple/EntityKey to Entity/Id?

Found an example, this is all the code it needs to have a MassIndexer working on top of Infinispan's Map/Reduce: https://github.com/infinispan/infinispan/blob/master/query/src/main/java/org/infinispan/query/impl/massindex/IndexingMapper.java#L40 Note it's initialize method which injects needed co

[hibernate-dev] Hibernate-ehcache 4.1.10.Final

Hi, Looks like Hibernate-core 4.1.10.Final is missing from some repositories and Hibernate-ehcache.4.1.0.Final from *all* repositories. Same goes for hibernate-entitymanager. Shouldn't these versions be in sync? ___ hibernate-dev mailing list hibernate-d

Re: [hibernate-dev] Hibernate-ehcache 4.1.10.Final

Hi Marc, On Mon, Mar 4, 2013 at 8:41 PM, Marc Schipperheyn wrote: > Looks like Hibernate-core 4.1.10.Final is missing from some repositories > and Hibernate-ehcache.4.1.0.Final from *all* repositories. Same goes for > hibernate-entitymanager. Shouldn't these versions be in sync? Which repositori

[hibernate-dev] Fwd: Hibernate-ehcache 4.1.10.Final

repo1.maven.org repo2.maven.org repository.jboss.org/nexus mvnrepository.com > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Fwd: Hibernate-ehcache 4.1.10.Final

On Mon, Mar 4, 2013 at 9:49 PM, Marc Schipperheyn wrote: > repo1.maven.org > repo2.maven.org It's in these repos as we are using them and you can find the artifact on search.maven.org. > repository.jboss.org/nexus https://repository.jboss.org/nexus/index.html#nexus-search;gav~org.hibernate~hibe

Re: [hibernate-dev] Fwd: Hibernate-ehcache 4.1.10.Final

Most repositories disable browsing, but only at the root level. Personally, I like to go directly to the url and see if the thing is there (or as Guillaume suggests using one of the search sites). https://repository.jboss.org/nexus/content/groups/public/org/hibernate/hibernate-core/4.1.10.Final/

Re: [hibernate-dev] Fwd: Hibernate-ehcache 4.1.10.Final

You're right. I was thrown off by a problem in my local maven rep which lead to Eclipse reporting that it couldn't find those libs and the sorting as I checked it. Sorry. Vriendelijke groet, Marc M.Schipperheyn MSW BV | Nova Zemblastraat 12-a, 1013 RK, Amsterdam