Re: [hibernate-dev] database names and identifier length
Thanks, got it now. Yes I think that would have value; my impression is that taking care of such things is a general expectations among users. In case it had to truncate[shorten?] identifier names we'd also need to make sure that doesn't introduce ambiguities with other column names, and - as a user - I'd expect a warning to be logged. Thanks, Sanne On 25 July 2015 at 22:18, Steve Ebersole wrote: > He is talking about native (sql) queries. If a user defines a native query > using his example column name > MY_SUPER_AWESOME_COLUMN_NAME_CANT_ALWAYS_BE_USED, then when we replace that > because they deploy on to "database product X" which limits identifier > lengths to 10... he worries that the users query now fails. But of course > he glosses over the fact that the app would not work on "database product X" > with or without this change because "database product X" simply would not > support a column named MY_SUPER_AWESOME_COLUMN_NAME_CANT_ALWAYS_BE_USED > (from say a mapping). > > I think in general the idea of trying to combine native sql queries and > database portability is just asking for trouble. > > On Sat, Jul 25, 2015 at 1:23 PM Sanne Grinovero wrote: >> >> Hi Max, could you make an example please? >> Looks like you are interpreting Steve's email in a different way than me. >> >> On 24 Jul 2015 21:43, "Max Rydahl Andersen" wrote: >>> >>> On 24 Jul 2015, at 16:48, Steve Ebersole wrote: >>> >>> > Do we want to consider automatically applying known database limits on >>> > various identifier lengths? This is trickier to implement than it >>> > might >>> > sound. And it would definitely need to wait for the reworking of >>> > annotation binding. But in general I wonder if y'all see this as a >>> > desirable feature. And if so, should that be just for implicit names? >>> > Or >>> > explicit names as well? >>> >>> I could see it be valuable for easier cross db testing, but all users >>> custom queries >>> would be easily broken unless you have something very deterministic. >>> >>> If we do it think I as a user would prefer at least get a warning or be >>> able to turn on "strict" mode >>> to catch issues where I did not realise >>> "MY_SUPER_AWESOME_COLUMN_NAME_CANT_ALWAYS_BE_USED". >>> >>> /max >>> http://about.me/maxandersen >>> >>> ___ >>> 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] MySQL versus MariaDB
Looks like we'll want to have both MariaDB and MySQL on ci.hibernate.org then: - https://hibernate.atlassian.net/browse/WEBSITE-383 On 22 July 2015 at 22:51, Steve Ebersole wrote: > https://hibernate.atlassian.net/browse/HHH-9969 > > On Wed, Jul 22, 2015 at 2:18 PM Steve Ebersole wrote: > >> As I have developed the matrix tests against MariaDB I have had in the >> back of my head whether we might want to develop a Dialect for MariaDB. As >> I understand it, MariaDB does strive to remain compatible with MySQL but it >> does offer some enhancements. And it might have some minor deviations. >> Today I think I found one such deviation, in their respective support for >> casting decimal/floating-point values. I came across this because of some >> failed tests. >> >> There are quite a few resolved issues in Jira wrt MySQL and casting. So I >> have to assume these tests work on MySQL which tells me there is a >> deviation in their behavior... >> >> The tests in question (more or less) do: "select ... cast( x as >> big_decimal ) ...". We understand big_decimal as java.sql.Types#NUMERIC >> for which the MySQL Dialect says to use "decimal" for casting purposes. >> >> On MariaDB at least "decimal" (no precision) leads to a data trunction. >> We are expecting a value like "12.39618530273" but get back "12.0". >> Because for MariaDB DECIMAL is equivalent to DECIMAL(10,0). >> >> So as it is, for this minor case at least the MySQL dialects work against >> MySQL databases (we assume) but fail against MariaDB databases. >> >> The other difficulty with a dialect specific for MariaDB is >> auto-detection. The MariaDB JDBC drivers report the underlying database as >> mysql. >> > ___ > 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] MariaDB on CI
On 23 July 2015 at 17:41, Steve Ebersole wrote: > Another change is to make sure our test user has create/drop privileges on > all databases, and to be able to create/drop databases: > > grant create, drop on *.* to 'hibernate_orm_test'@'localhost'; > > We will need similar for the other databases too. That limitation was actually intentional. I think most users will have Hibernate connect via a limited-privileged user, so you don't think there would be value in us actually testing using the more limited privileges? I'm ok to change it, but - unless it's too inconvenient to get current tests reliable - I'd prefer to create a second user for when test infrastructure code need to create/drop databases. Why are you needing this? -- Sanne > > > > On Tue, Jul 21, 2015 at 6:02 PM Sanne Grinovero wrote: >> >> On 20 July 2015 at 17:41, Steve Ebersole wrote: >> > Sanne for MariaDB (and MySQL if we ever add it) we need to add at least >> > one >> > more setting: >> > >> > sql-mode="traditional" >> >> I've applied this change. >> >> --Sanne >> >> > >> > We could probably get away with less ANSI compliant mode, but after days >> > playing with this I just want to cover my bases :) >> > >> > On Sat, Jul 18, 2015 at 3:37 PM Sanne Grinovero >> > wrote: >> >> >> >> Thanks, great suggestions! >> >> I've applied these and some more. >> >> >> >> The MariaDB configuration: >> >> - >> >> >> >> https://github.com/hibernate/ci.hibernate.org/blob/master/roles/mariadb-server/files/my.cnf >> >> >> >> The PosgreSQL configuration files: >> >> - >> >> >> >> https://github.com/hibernate/ci.hibernate.org/blob/master/roles/postgres-server/files/pg_hba.conf >> >> - >> >> >> >> https://github.com/hibernate/ci.hibernate.org/blob/master/roles/postgres-server/files/postgresql.conf >> >> >> >> Both are running with these settings now on each CI slave. >> >> Sanne >> >> >> >> On 18 July 2015 at 00:49, Steve Ebersole wrote: >> >> > [18:45] whoa.. >> >> > [18:45] sannegrinovero: we definitely need this for >> >> > mariadb >> >> > on >> >> > ci... >> >> > [18:46] sync_binlog=0 innodb_flush_log_at_trx_commit=0 >> >> > innodb_doublewrite=0 >> >> > [18:46] tests were much faster >> >> > >> >> > These were suggested to me on the #mariadb list. I added them to my >> >> > local >> >> > /etc/my.cnf file and the tests were significantly faster. >> >> > ___ >> >> > 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] 4.2.20.Final and SourceForge problems; delaying 4.3.11.Final until next week
Hi, On Sat, Jul 25, 2015 at 12:11:41AM -0400, Gail Badner wrote: > I am finished with the 4.2.20.Final release, except for uploading > distributions due to problems at SourceForge. FYI, I am having the same issue. I am waiting for a week now to upload the Validator release. Initially, there were even no buttons to create folders or upload anything. Now they are back, but don't work (I've just tried again). ssh upload does not work either. SourceForge had some major outage, but seems unable to full recover. I am not sure how much longer we should wait. Right now I am drawn between these options * announce the release mentioning that the artifacts will be uploaded if and when SourceForge works again * upload the artifacts to GitHub and link to there * keep waiting --Hardy pgp0BJLj7dHB6.pgp Description: PGP signature ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] in.relation.to local building, Fedora 22
On Sat, Jul 25, 2015 at 03:28:51PM +, Steve Ebersole wrote: > FWIW the check command failed, but then `rake preview` seems to run fine (I > can view the site locally). The 'check' task is obsolete. It really only verified bundler and rake were installed. I am in the process of updating the readme and will remove the mention of the 'check' task at the same time. --Hardy pgp6EEUjqri8b.pgp Description: PGP signature ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
