[hibernate-dev] HipChat rooms
Hi, lately there is some interest in OrientDB for Hibernate OGM. This is not currently in the OGM roadmap but I wanted to help potential contributros. I've createad a room for OGM-855 using the JIRA funcitonality accessible by Guests. It seems though theat Guest cannot see the log of the room and that when a user send me an invite it becomes part of the hibernate team. Is that OK? Or do we have some limitation about accepting new users? Am I doing something wrong? Cheers, Davide ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HipChat rooms
I was wrong about the log for guests, the HipChat documentation states: "The room's chat history, including files, are only visible to guests from the point they logged in. " So, it's better than I thought On Tue, Feb 2, 2016 at 12:46 PM, Davide D'Alto wrote: > Hi, > lately there is some interest in OrientDB for Hibernate OGM. > This is not currently in the OGM roadmap but I wanted to help potential > contributros. > > I've createad a room for OGM-855 using the JIRA funcitonality accessible > by Guests. > It seems though theat Guest cannot see the log of the room and that when a > user send me an invite it becomes part of the hibernate team. > > Is that OK? Or do we have some limitation about accepting new users? > Am I doing something wrong? > > Cheers, > Davide > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HipChat rooms
+1 to approve any reasonable request to join us. I think the functionality is there only to be prevent spammers and kick out misbehaving people; we have no intent of keeping any goodwilling developer out. On 2 February 2016 at 12:49, Davide D'Alto wrote: > I was wrong about the log for guests, the HipChat documentation states: > > "The room's chat history, including files, are only visible to guests from > the point they logged in. " > > So, it's better than I thought > > > On Tue, Feb 2, 2016 at 12:46 PM, Davide D'Alto wrote: > >> Hi, >> lately there is some interest in OrientDB for Hibernate OGM. >> This is not currently in the OGM roadmap but I wanted to help potential >> contributros. >> >> I've createad a room for OGM-855 using the JIRA funcitonality accessible >> by Guests. >> It seems though theat Guest cannot see the log of the room and that when a >> user send me an invite it becomes part of the hibernate team. >> >> Is that OK? Or do we have some limitation about accepting new users? >> Am I doing something wrong? >> >> Cheers, >> Davide >> > ___ > 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
Re: [hibernate-dev] HipChat rooms
+1, this is not for the hibernate team. Rather for everyone. > On 02 Feb 2016, at 15:24, Sanne Grinovero wrote: > > +1 to approve any reasonable request to join us. > I think the functionality is there only to be prevent spammers and > kick out misbehaving people; we have no intent of keeping any > goodwilling developer out. > > On 2 February 2016 at 12:49, Davide D'Alto wrote: >> I was wrong about the log for guests, the HipChat documentation states: >> >> "The room's chat history, including files, are only visible to guests from >> the point they logged in. " >> >> So, it's better than I thought >> >> >> On Tue, Feb 2, 2016 at 12:46 PM, Davide D'Alto wrote: >> >>> Hi, >>> lately there is some interest in OrientDB for Hibernate OGM. >>> This is not currently in the OGM roadmap but I wanted to help potential >>> contributros. >>> >>> I've createad a room for OGM-855 using the JIRA funcitonality accessible >>> by Guests. >>> It seems though theat Guest cannot see the log of the room and that when a >>> user send me an invite it becomes part of the hibernate team. >>> >>> Is that OK? Or do we have some limitation about accepting new users? >>> Am I doing something wrong? >>> >>> Cheers, >>> Davide >>> >> ___ >> 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 mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] [Search] Range faceting for Longs and Dates not taking into account hasZeroCountsIncluded
Hi, While playing with ElasticSearch faceting (and having tests failing due to that), I noticed that for Longs and Dates, the preexisting range faceting doesn't take into account facetRequest.hasZeroCountsIncluded(). See https://github.com/hibernate/hibernate-search/blob/master/engine/src/main/java/org/hibernate/search/query/engine/impl/QueryHits.java#L308 and a few lines below for floating point ranges which take into account this very parameter. Is this something expected? Should I prepare a PR to fix it? -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Search] Travis support
Hi, FWIW, I also added Travis support to OGM (mostly to see if we could do it easily with all the NoSQL databases supported) here: https://travis-ci.org/gsmet/hibernate-ogm/ https://github.com/gsmet/hibernate-ogm/blob/travis-support/.travis.yml What I also find interesting in Travis is that you can easily enable CI for your own fork once the .travis.yml is committed to the main repository. -- Guillaume On Thu, Jan 28, 2016 at 6:26 PM, Guillaume Smet wrote: > Hi Sanne, > > On Thu, Jan 28, 2016 at 3:23 PM, Sanne Grinovero > wrote: > >> I am a bit skeptical as we have CI working already on ci.hibernate.org >> and having limited people we can't really afford to fix things which >> already work. >> > > I perfectly understand that. I wanted to experiment it without bothering > you about it. > > >> To summarize what I like of Travis: >> - simple configuration >> - not much maintenance from our side >> - your recommendation counts >> - they pay the bills? >> - you say that it's very popular among Java developers. >> >> About the popularity point, you surprised me. I honestly thought that >> we should stay on Jenkins because that was the most popular one. Do >> you have some data to back that nowadays people are more familiar with >> Travis? >> > > It's very widespread in the Open Source projects running on GitHub, either > in Java, Ruby, PHP, Python and so on. > > HikariCP for instance uses Travis and there are a lot of others projects > using it: https://github.com/brettwooldridge/HikariCP . > > We use Jenkins at my company too for our private projects but we use > Travis for our Open Source ones. > > >> Finally I have been burned several times by not having "root access" >> on the whole thing. I guess Docker might make this reasoning moot now, >> but it's something to consider. >> It's also quite important that we make sure our releases are created >> in a reliable environment, so there's the trust issue of delegating >> the keys to the kingdom to a third party. I'd even like it we could >> start "signing" the artifacts we release as some users mentioned that >> this would be important for them. >> > > Yes, Travis won't replace the release tasks. I think it's good for the day > to day builds and PR builds and we should only use it for that - if we > decide to use it. > > >> Sorry to be skeptical, I didn't mean to stress the negative aspects >> but to clarify that there are many aspects to consider for such a >> move. >> I'm definitely open to consider using it for a subset of jobs, like >> you mentioned the PR review system might be a good fit. >> It's also a good thing for sure to test in additional environments: >> can it also run jobs on Windows and OSX ? We're missing that.. we >> could fix the lack of Windows via AWS but that has a steep price tag.. >> I'll rather volunteer an old laptop from home. >> > > They have OSX support but it's sparse. It's mostly here to test MacOS and > iOS apps. They don't have Windows support. > > -- > Guillaume > > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] SchemaManagementTool changes for 5.1 (was Re: 5.1 tentative release date)
Part of the work here is going to require significant changes to org.hibernate.tool.hbm2ddl.SchemaExport, org.hibernate.tool.hbm2ddl.SchemaUpdate and org.hibernate.tool.hbm2ddl.SchemaValidator. Significant as in current usages would not work at all. So does it make sense to do those changes, or to simply drop those classes? On Fri, Jan 29, 2016 at 1:15 PM Steve Ebersole wrote: > I am debating with myself about > reusing `javax.persistence.schema-generation.database.action` and > `javax.persistence.schema-generation.scripts.action` > in terms of this new unified support. The debate point being the fact that > we'd have to have those accept an extended range of values which > potentially hurts users in terms of JPA provider portability. For example, > if they have: > > javax.persistence.schema-generation.database.action=validate > > Hibernate would understand that, but other providers likely would not. > This is beyond the concept of "strict compliance" I started in SQM in my > opinion. Here we are moving toward a unification, meaning we expect people > to use this. > > So do we reuse the JPA names? > > On a related note.. in regards to the fact that JPA splits action between > script and database target whereas hbm2ddl defines just a singular action > value... does anyone know of a real case where someone defines different > actions between script and database? I mean aside from one being NONE. I > mean cases where they say we should do "create" for scripts but send > "drop-and-create" to the database? That just seems odd to me. I think we > have to account for the split since we have to account for JPA, and that > model fits both. I was just curious > > > > > On Fri, Jan 29, 2016 at 12:01 PM Steve Ebersole > wrote: > >> On Fri, Jan 29, 2016 at 10:40 AM Gunnar Morling >> wrote: >> >>> 2016-01-29 17:18 GMT+01:00 Steve Ebersole : >>> > I also plan on adding an @Incubating annotation for just such things :) >>> >>> Yes, please. We have an annotation @Experimental in OGM which we use >>> for tagging APIs under development. >>> >> >> See https://hibernate.atlassian.net/browse/HHH-10487. I also started a >> separate discussion about this on the dev list. >> >> >> BTW, as an extension to changing SchemaManagementTool another thing I'd >> like to add is some hook account for Envers use cases. Specifically the >> idea there is to be able to do a few things: >> 1) perform a selective create/drop. selective in terms of just certain >> objects. This may be achievable through the new filter concept, although >> we'd at least need a way to identify Envers tables from non-Envers tables. >> Think of starting to use Hibernate+Envers on a schema that already exists. >> 2) perform "actions". This is maybe beyond "schema tooling"; perhaps it >> is more of a SessionFactory boot concept. But one thing Envers misses >> today that would be good to add is the ability to "prime" the audit >> tables. Meaning, for audited entities that do not have entries in their >> audit table, create one. This for sure goes beyond simple SQL statements >> though. >> > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] SchemaManagementTool changes for 5.1 (was Re: 5.1 tentative release date)
i think it's better to drop On 2 February 2016 at 21:10, Steve Ebersole wrote: > Part of the work here is going to require significant changes > to org.hibernate.tool.hbm2ddl.SchemaExport, > org.hibernate.tool.hbm2ddl.SchemaUpdate > and org.hibernate.tool.hbm2ddl.SchemaValidator. Significant as in current > usages would not work at all. So does it make sense to do those changes, > or to simply drop those classes? > > > On Fri, Jan 29, 2016 at 1:15 PM Steve Ebersole > wrote: > > > I am debating with myself about > > reusing `javax.persistence.schema-generation.database.action` and > `javax.persistence.schema-generation.scripts.action` > > in terms of this new unified support. The debate point being the fact > that > > we'd have to have those accept an extended range of values which > > potentially hurts users in terms of JPA provider portability. For > example, > > if they have: > > > > javax.persistence.schema-generation.database.action=validate > > > > Hibernate would understand that, but other providers likely would not. > > This is beyond the concept of "strict compliance" I started in SQM in my > > opinion. Here we are moving toward a unification, meaning we expect > people > > to use this. > > > > So do we reuse the JPA names? > > > > On a related note.. in regards to the fact that JPA splits action between > > script and database target whereas hbm2ddl defines just a singular action > > value... does anyone know of a real case where someone defines different > > actions between script and database? I mean aside from one being NONE. > I > > mean cases where they say we should do "create" for scripts but send > > "drop-and-create" to the database? That just seems odd to me. I think > we > > have to account for the split since we have to account for JPA, and that > > model fits both. I was just curious > > > > > > > > > > On Fri, Jan 29, 2016 at 12:01 PM Steve Ebersole > > wrote: > > > >> On Fri, Jan 29, 2016 at 10:40 AM Gunnar Morling > >> wrote: > >> > >>> 2016-01-29 17:18 GMT+01:00 Steve Ebersole : > >>> > I also plan on adding an @Incubating annotation for just such things > :) > >>> > >>> Yes, please. We have an annotation @Experimental in OGM which we use > >>> for tagging APIs under development. > >>> > >> > >> See https://hibernate.atlassian.net/browse/HHH-10487. I also started a > >> separate discussion about this on the dev list. > >> > >> > >> BTW, as an extension to changing SchemaManagementTool another thing I'd > >> like to add is some hook account for Envers use cases. Specifically the > >> idea there is to be able to do a few things: > >> 1) perform a selective create/drop. selective in terms of just certain > >> objects. This may be achievable through the new filter concept, > although > >> we'd at least need a way to identify Envers tables from non-Envers > tables. > >> Think of starting to use Hibernate+Envers on a schema that already > exists. > >> 2) perform "actions". This is maybe beyond "schema tooling"; perhaps it > >> is more of a SessionFactory boot concept. But one thing Envers misses > >> today that would be good to add is the ability to "prime" the audit > >> tables. Meaning, for audited entities that do not have entries in their > >> audit table, create one. This for sure goes beyond simple SQL > statements > >> though. > >> > > > ___ > 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
Re: [hibernate-dev] SchemaManagementTool changes for 5.1 (was Re: 5.1 tentative release date)
When you say dropping, what would be the alternative for CLI users? It seems like a strong change to do in a minor revision. What are the required changes you need to do here? My hope would have been that the API of these tools would not have to change. 2016-02-02 22:10 GMT+01:00 Steve Ebersole : > Part of the work here is going to require significant changes to > org.hibernate.tool.hbm2ddl.SchemaExport, > org.hibernate.tool.hbm2ddl.SchemaUpdate and > org.hibernate.tool.hbm2ddl.SchemaValidator. Significant as in current > usages would not work at all. So does it make sense to do those changes, or > to simply drop those classes? > > > On Fri, Jan 29, 2016 at 1:15 PM Steve Ebersole wrote: >> >> I am debating with myself about reusing >> `javax.persistence.schema-generation.database.action` and >> `javax.persistence.schema-generation.scripts.action` in terms of this new >> unified support. The debate point being the fact that we'd have to have >> those accept an extended range of values which potentially hurts users in >> terms of JPA provider portability. For example, if they have: >> >> javax.persistence.schema-generation.database.action=validate >> >> Hibernate would understand that, but other providers likely would not. >> This is beyond the concept of "strict compliance" I started in SQM in my >> opinion. Here we are moving toward a unification, meaning we expect people >> to use this. >> >> So do we reuse the JPA names? >> >> On a related note.. in regards to the fact that JPA splits action between >> script and database target whereas hbm2ddl defines just a singular action >> value... does anyone know of a real case where someone defines different >> actions between script and database? I mean aside from one being NONE. I >> mean cases where they say we should do "create" for scripts but send >> "drop-and-create" to the database? That just seems odd to me. I think we >> have to account for the split since we have to account for JPA, and that >> model fits both. I was just curious >> >> >> >> >> On Fri, Jan 29, 2016 at 12:01 PM Steve Ebersole >> wrote: >>> >>> On Fri, Jan 29, 2016 at 10:40 AM Gunnar Morling >>> wrote: 2016-01-29 17:18 GMT+01:00 Steve Ebersole : > I also plan on adding an @Incubating annotation for just such things > :) Yes, please. We have an annotation @Experimental in OGM which we use for tagging APIs under development. >>> >>> >>> See https://hibernate.atlassian.net/browse/HHH-10487. I also started a >>> separate discussion about this on the dev list. >>> >>> >>> BTW, as an extension to changing SchemaManagementTool another thing I'd >>> like to add is some hook account for Envers use cases. Specifically the >>> idea there is to be able to do a few things: >>> 1) perform a selective create/drop. selective in terms of just certain >>> objects. This may be achievable through the new filter concept, although >>> we'd at least need a way to identify Envers tables from non-Envers tables. >>> Think of starting to use Hibernate+Envers on a schema that already exists. >>> 2) perform "actions". This is maybe beyond "schema tooling"; perhaps it >>> is more of a SessionFactory boot concept. But one thing Envers misses today >>> that would be good to add is the ability to "prime" the audit tables. >>> Meaning, for audited entities that do not have entries in their audit table, >>> create one. This for sure goes beyond simple SQL statements though. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
