Re: [VOTE] Release all new website for Empire-db

2022-03-11 Thread ivan nemeth
+1

On Fri, Mar 11, 2022 at 4:09 PM Rainer Döbele 
wrote:

> Dear fellow committers and PMC members,
>
> finally, after releasing version 3.0.0 I am asking you all to approve of
> publishing our all new website for Empire-db.
>
> The preview for the new website can be found here:
> https://empire-db.apache.org/preview-v3
>
> Please vote one more time:
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Thanks,
> Rainer
>
> P.S. I'll give it a +1
>
> - Original Message -
> from: Rainer Döbele 
> to: dev@empire-db.apache.org; priv...@empire-db.apache.org
> re: [VOTE] Release Apache Empire-db 3.0.0 (rc1)
>
> Hi all,
>
> there has been a lot going on recently, and I am happy to announce, that
> Empire-db 3.0.0 is ready for distribution.
> Thanks to all contributors for participating.
>
> I have prepared a release candidate (apache-empire-db-3.0.0-rc1) which I
> am asking for you to approve.
>
> The changelog can be found here:
>
> https://gitbox.apache.org/repos/asf?p=empire-db.git;a=blob;f=CHANGELOG.txt;h=1c622e19de89988c1081de8cecc0c79c3101a740;hb=0c4a0a55c8ec655abd6bce273529d9f94f56
>
> Git tag:
>
> https://gitbox.apache.org/repos/asf?p=empire-db.git;a=commit;h=cfb371df866e7cdf8c6d3f52780e789c467a3d72
>
> Maven staging repository:
> https://repository.apache.org/content/repositories/orgapacheempire-db-1009
>
> Distribution files are located here:
>
> https://dist.apache.org/repos/dist/dev/empire-db/apache-empire-db-3.0.0-rc1/
>
> RAT report can be found here:
>
> https://dist.apache.org/repos/dist/dev/empire-db/apache-empire-db-3.0.0-rc1/rat.txt
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> After publishing the release I will prepare the new website for
> publication and then ask you for a vote on that too.
> A preview of the new website can already be found here:
> https://empire-db.apache.org/preview-v3
>
> Looking forward to receiving your vote.
>
> Best regards,
>
> Rainer
>
>


Re: [VOTE] Release Apache Empire-db 3.0.0 (rc1)

2022-03-08 Thread ivan nemeth
+1

On Tue, Mar 8, 2022 at 4:42 PM Rainer Döbele  wrote:

> Hi all,
>
> there has been a lot going on recently, and I am happy to announce, that
> Empire-db 3.0.0 is ready for distribution.
> Thanks to all contributors for participating.
>
> I have prepared a release candidate (apache-empire-db-3.0.0-rc1) which I
> am asking for you to approve.
>
> The changelog can be found here:
>
> https://gitbox.apache.org/repos/asf?p=empire-db.git;a=blob;f=CHANGELOG.txt;h=1c622e19de89988c1081de8cecc0c79c3101a740;hb=0c4a0a55c8ec655abd6bce273529d9f94f56
>
> Git tag:
>
> https://gitbox.apache.org/repos/asf?p=empire-db.git;a=commit;h=cfb371df866e7cdf8c6d3f52780e789c467a3d72
>
> Maven staging repository:
> https://repository.apache.org/content/repositories/orgapacheempire-db-1009
>
> Distribution files are located here:
>
> https://dist.apache.org/repos/dist/dev/empire-db/apache-empire-db-3.0.0-rc1/
>
> RAT report can be found here:
>
> https://dist.apache.org/repos/dist/dev/empire-db/apache-empire-db-3.0.0-rc1/rat.txt
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> After publishing the release I will prepare the new website for
> publication and then ask you for a vote on that too.
> A preview of the new website can already be found here:
> https://empire-db.apache.org/preview-v3
>
> Looking forward to receiving your vote.
>
> Best regards,
>
> Rainer
>
>


Re: [VOTE] Release Apache Empire-db 2.5.1 (rc1)

2022-01-19 Thread ivan nemeth
+1

On Tue, Jan 18, 2022 at 5:22 PM Rainer Döbele  wrote:

> Hi all,
>
> since our last release is of May 2020, it is about time for a new release.
> I have prepared a release candidate (apache-empire-db-2.5.1-rc1) which I
> am asking for you to approve.
> Info about the release process can be found here:
> http://www.apache.org/dev/release#approving-a-release
>
> The changelog can be found here:
>
> https://gitbox.apache.org/repos/asf?p=empire-db.git;a=blob;f=CHANGELOG.txt;h=bca5c5291acf0d472ee04f0cd869d9a9da4e1aba;hb=refs/tags/empire-db-parent-2.5.1
>
> Git tag:
>
> https://gitbox.apache.org/repos/asf?p=empire-db.git;a=commit;h=7b23e39770d417af85739c85a8ac819bd103241c
>
> Maven staging repository:
> https://repository.apache.org/content/repositories/orgapacheempire-db-1008
>
> Distribution files are located here:
>
> https://dist.apache.org/repos/dist/dev/empire-db/apache-empire-db-2.5.1-rc1/
>
> RAT report can be found here:
>
> https://dist.apache.org/repos/dist/dev/empire-db/apache-empire-db-2.5.1-rc1/rat.txt
>
> Vote open for 96 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Looking forward to receiving your vote.
>
> Best regards,
>
> Rainer
>


Re: [VOTE] Release Apache Empire-db 2.5.0 (rc1)

2020-05-06 Thread ivan nemeth
+1

On Mon, May 4, 2020 at 6:35 PM Rainer Döbele  wrote:

> Hi all,
>
>
>
> it took a while, but now we have just prepared the apache-empire-db-2.5.0
> release and we are now looking for approval to publish the release.
>
> More info on release requirements can be found here:
> http://www.apache.org/dev/release#approving-a-release
>
>
>
> The changelog can be found here:
>
>
> https://gitbox.apache.org/repos/asf?p=empire-db.git;a=blob;f=CHANGELOG.txt;h=859267830592e736ce957a7e9993087b62245361;hb=707de6298d6f35c5360c47a958b2d4736df686ee
>
>
>
> Git tag:
>
>
> https://gitbox.apache.org/repos/asf?p=empire-db.git;a=tag;h=62113dd056e5e8fdfa7264cba2620cbf83729d1a
>
>
>
> Maven staging repository:
>
> https://repository.apache.org/content/repositories/orgapacheempire-db-1007
>
>
>
> Distribution files are located here:
>
>
> https://dist.apache.org/repos/dist/dev/empire-db/apache-empire-db-2.5.0-rc1/
>
>
>
> RAT report can be found here:
>
>
> https://dist.apache.org/repos/dist/dev/empire-db/apache-empire-db-2.5.0-rc1/rat.txt
>
>
>
> Vote open for 96 hours.
>
> [ ] +1
>
> [ ] +0
>
> [ ] -1
>
>
>
> Looking forward to receiving your vote.
>
> Regards,
>
> Rainer
>
>
>


Re: [VOTE] Releasing version 2.5.0

2020-02-14 Thread ivan nemeth
+1

On Fri, Feb 14, 2020 at 10:54 AM Sascha Geissler 
wrote:

> +1
>
> Dimitar Simeonov  schrieb am Fr., 14. Feb.
> 2020, 10:38:
>
> > +1
> >
> >
> >
> > Am Freitag, Februar 14, 2020, 10:26 schrieb Rainer Döbele <
> > doeb...@esteam.de>:
> >
> >  
> > Hello everybody,
> >
> >
> >
> > over the last 12 months we have collected many significant improvements
> > and bugfixes.
> >
> > From my point of view, the we should now proceed and start the release
> > process for version 2.5.0.
> >
> >
> >
> > Please give us your vote on whether to start the release process.
> >
> >
> >
> > Vote open for 72 hours.
> >
> >
> >
> > [ ] +1
> >
> > [ ] +0
> >
> > [ ] -1
> >
> >
> >
> > Regards
> >
> > Rainer
> >
> >
> >
> >
> >
> >
>


Re: Timestamp can not be converted to TIMESTAMP

2019-11-13 Thread ivan nemeth
Hi Daniel,

Timestamp is not a datetime type in SQL Server, it's a synonym for
rowversion which is a incrementing number for versioning. See
https://docs.microsoft.com/en-us/sql/t-sql/data-types/rowversion-transact-sql?view=sql-server-ver15

You should use datetime2:

 Alter Table Timetable  ADD UPDATE_TIMESTAMP *datetime2*;


Regards,
Ivan


On Wed, Nov 13, 2019 at 10:09 AM Daniel Wenning <
daniel.wenn...@htwg-konstanz.de> wrote:

> Hi,
>
> I am trying to create an UPDATE_TIMESTAMP as version column.
>
> In code i got
> UPDATE_TIMESTAMP= addColumn("UPDATE_TIMESTAMP", DataType.TIMESTAMP,
> 0, true);
>
> and in SQLSERVER i got
> Alter Table Timetable  ADD UPDATE_TIMESTAMP Timestamp;
>
> When trying to insert or update a new entry for Timetable i get the error
>
> INFO  [2019/11/13 09:48]: An Error occured. Message is: The database
> operation failed. Native error is: Die Konvertierung von "timestamp" in
> "TIMESTAMP" wird nicht unterstützt.  at
> org.apache.empire.exceptions.EmpireException.log(EmpireException.java:124)
> org.apache.empire.db.exceptions.EmpireSQLException: The database operation
> failed. Native error is: Die Konvertierung von "timestamp" in "TIMESTAMP"
> wird nicht unterstützt.
>
> What is the Error here?
>
> Thanks in advance!
>
> --
> Sincerely
>
> Daniel Wenning
> 8th Semester
> Angewandte Informatik
> HTWG Konstanz
>
>


Re: [VOTE] Release Apache Empire-db 2.4.6 (rc2)

2017-01-12 Thread ivan nemeth
+1

Thanks Rainer, Jan & Francis

Jan Glaubitz  ezt írta (időpont: 2017. jan. 12., Cs,
10:04):

> Not really, its just an address 路‍♂️ and I dont think you wanna use it
> for real E-Mails. Just dont lose your private key ;-)
>
> +1
>
> Von meinem iPhone gesendet
>
> > Am 12.01.2017 um 09:53 schrieb Rainer Döbele :
> >
> > I have now updated the KEYS file.
> >
> > (Unfortunately I have created the key using my business email rather
> than my apache.org email - does it matter?)
> >
> > Regards,
> > Rainer
> >
> >> From: Francis De Brabandere [mailto:franci...@gmail.com]
> >> To: dev 
> >> Subject: Re: [VOTE] Release Apache Empire-db 2.4.6 (rc2)
> >>
> >> So once the KEYS file is updated this is a +1 from me
> >>
> >> On 10 January 2017 at 15:41, Francis De Brabandere  >
> >> wrote:
> >>
> >>> @Jan, you can import the signature from the mit keyserver gpg
> >>> --keyserver pgpkeys.mit.edu --recv-key 0B5DFB51
> >>>
> >>> @Rainer the KEYS file is still not updated
> >>> https://dist.apache.org/repos/dist/release/empire-db/KEYS
> >>>
> >>> Cheers,
> >>> F
> >>>
> >>>
> >>>
>  On 10 January 2017 at 08:39, Jan Glaubitz  wrote:
> 
>  Hello Rainer,
> 
>  SHA works now (but: maybe we should use at least SHA256?)
> 
>  I'm still unable to verify the PGP signature.
> 
>  - jan
> 
>  Von meinem iPhone gesendet
> 
> > Am 10.01.2017 um 08:18 schrieb Rainer Döbele :
> >
> > Hi Jan,
> >
> > you are absolutely right: instead of the sha hash the file
> > contained
>  the md5 hash.
> > I have corrected it now.
> > Please check again.
> >
> > Regards
> > Rainer
> >
> >> From: j...@glaubitz.org [mailto:j...@glaubitz.org]
> >> To: dev@empire-db.apache.org
> >> Subject: Re: [VOTE] Release Apache Empire-db 2.4.6 (rc2)
> >>
> >> Hello Rainer,
> >>
> >> how did you create the sha sum? I cant validate its correct:
> >>
> >> [jan ~/tmp] sha1 apache-empire-db-2.4.6-dist.zip
> >> SHA1 (apache-empire-db-2.4.6-dist.zip) =
> >> 9d0f4e28334561e15458671b7b093b7b3cc5f9cb
> >>
> >> yours look a little bit short...?
> >>
> >>
> >> Which key did you use to create the PGP signature? I can't verify
> >> with
>  they
> >> KEYS file from the website:
> >>
> >> [jan ~/tmp] gpg --verify apache-empire-db-2.4.6-dist.zip.asc
> >> gpg: Warning: using insecure memory!
> >> gpg: assuming signed data in 'apache-empire-db-2.4.6-dist.zip'
> >> gpg: Signature made Mon Jan  9 11:46:48 2017 CET
> >> gpg:using RSA key 0279D7D50B5DFB51
> >> gpg: Can't check signature: No public key
> >>
> >> - jan
> >>
> >> Zitat von Rainer Döbele :
> >>
> >>> Hi all,
> >>>
> >>> Due to an incorrect distribution file I have cancelled rc1 and
> >>> prepared a second release candidate for version 2.4.6.
> >>> Please do all check and vote again on this release candidate.
> >>>
> >>> A list of all resolved issues for this release can be found here:
> >>> https://issues.apache.org/jira/browse/EMPIREDB-
> >> 250?jql=project%20%3D%2
> >>> 0EMPIREDB%20AND%20fixVersion%20in%20(empire-db-
> >> 2.4.6%2C%20empire-db-2.
> >>>
> >>
> >> 4.5)%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20create
> >> d%20ASC
> >>>
> >>> Maven staging repository:
> >>> https://repository.apache.org/content/repositories/orgapache
>  empire-db-
> >>> 1004/
> >>>
> >>> The distribution files are located here:
> >>> https://dist.apache.org/repos/dist/dev/empire-db/apache-empire-
> >> db
> >>> -2.4
>  .
> >>> 6-rc2/
> >>>
> >>> The Rat report for the tag is available here:
> >>> https://dist.apache.org/repos/dist/dev/empire-db/apache-empire-
> >> db
> >>> -2.4
>  .
> >>> 6-rc2/rat.txt
> >>>
> >>> Vote open for 72 hours.
> >>>
> >>> [ ] +1
> >>> [ ] +0
> >>> [ ] -1
> >>
> >>
> >
> 
> 
> >>>
>
>


Re: [VOTE] Release Apache Empire-db 2.4.5 (rc1)

2016-11-10 Thread ivan nemeth
Hi Rainer,

Spring implementation is missing from the release.

Regards,
Ivan

Rainer Döbele  ezt írta (időpont: 2016. nov. 10., Cs,
17:04):

> Hi all,
>
> We have just prepared a 2.4.5 release and we are now looking for approval
> of the PMC to publish the release.
>
> A list of all resolved issues for this release can be found here:
>
> https://issues.apache.org/jira/browse/EMPIREDB-184?jql=project%20%3D%20EMPIREDB%20AND%20fixVersion%20%3D%20empire-db-2.4.5%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>
> Maven staging repository:
> https://repository.apache.org/content/repositories/orgapacheempire-db-1002/
>
> The distribution files are located here:
>
> https://dist.apache.org/repos/dist/dev/empire-db/apache-empire-db-2.4.5-rc1/
>
> The Rat report for the tag is available here:
>
> https://dist.apache.org/repos/dist/dev/empire-db/apache-empire-db-2.4.5-rc1/rat.txt
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>


Re: Release time?

2016-10-31 Thread Ivan Nemeth
Hi Rainer,

I've closed issue EMPIREDB-227 (Spring int), it's ready for release.

Regards,
Ivan


Ivan Nemeth <ivan.nem...@gmail.com> ezt írta (időpont: 2016. okt. 29., Szo,
18:39):

> Hi Rainer,
>
> I've to make some minor changes, but I'm going to finish it in a few days.
> Is this ok?
>
> Thanks,
> Ivan
>
> Rainer Döbele <doeb...@esteam.de> ezt írta (időpont: 2016. okt. 29., Szo
> 13:26):
>
> Hi all,
>
> It's been a while since we had our last public release and there has been
> some work done since.
>
> I would recommend to prepare a new release and have a vote on it soon.
> If anyone is still working on something, please let me know.
>
> Can anyone please check, if the following issues can be closed:
>
> EMPIREDB-227 Spring Integration
> EMPIREDB-244 Add support of WITH clause for oracle and postgresql
> EMPIREDB-247 Add Support for "insertOrUpdate" ("UPSERT")
>
> Regards,
> Rainer
>
>


Re: Bug with DBColumnExpr.multiplyWith and divide

2016-09-20 Thread ivan nemeth
Hi Rainer,

ok, I see, just one last remark, that at the same time the same logic
doesn't apply for OR and AND expressions, I mean you can't write

SELECT t1.* FROM T t1
WHERE *(t1.A = 1 OR t1.A = 2 OR t1.A = 3)  AND t1.B = 10*

instead the resulting sql will have a lot of parenthesis for each DBExpr.

Regards,
Ivan



Rainer Döbele <doeb...@esteam.de> ezt írta (időpont: 2016. szept. 9., P,
10:01):

> Hi Ivan,
>
> originally it was like you are proposing, but we had to change it and
> introduce the parentheses() function.
>
> I cannot remember exactly when this was done (2-3 years at least), but it
> was a design decision, that the developer must have full control over the
> generated SQL, even if that means that the Java code gets more verbose.
>
> How else would you e.g. achieve be able to achieve this:
>
> SELECT (t1.A + t1.B + t1.C + t1.D) * 2.0
>
> Regards,
> Rainer
>
> ____
> from: Ivan Nemeth [ivan.nem...@gmail.com]
> to: dev@empire-db.apache.org
> subject: Re: Bug with DBColumnExpr.multiplyWith and divide
>
> Hi Rainer,
>
> (JIRA is now ok, it was my fault.)
>
> Ok, I see that parenthesis solves my problem, but I think that an
> expression builder written in Java should follow Java rules. If I write the
> same expression with BigDecimals
>
> A.add(B).multiply(C) it is translated to (A + B) * C
>
> As a Java developer I would expect that DBColumnExpr works the same way. At
> the time when I write an Empire expression in *Java *I don't want to take
> care how it is translated to *SQL*. I understand that too many parenthesis
> may lead to a hard-to-read sql (have you seen any Hibernate generated sql?
> :D), but with parenthesis() the Java code will be much more verbose. The
> main advantage of a query builder is that you have to work with the
> generated sql only a few times. Not to mention that my query is already
> hard to read with 2-3 subqueries and joins, so I have to use some sql
> formatter to check the generated code.
>
> Moreover what I've suggested is only needed if 1. the expression is a
> DBCalcExpr and 2. the op is multiply or divide.
>
> Regards,
> Ivan
> …
>
>
> >
> >
> >
> >
> > Rainer Döbele <doeb...@esteam.de> ezt írta (időpont: 2016. szept. 8.,
> Cs,
> > 21:49):
> >
> >> Hi Ivan,
> >>
> >> I don't know about the JIRA issue. As far as I know anybody who is
> logged
> >> in can create issues.
> >> I have no knowledge about granting or refusing access to anybody.
> >>
> >> But I do have knowledge about the parenthesis issue.
> >> We do not automatically create parenthesis as it imposes some
> >> restrictions or at least might make complex expressions unreadable.
> >> Hence, just as in real life, you have to specifically make your
> >> parentheses where you need them.
> >>
> >> In your case I guess
> >>
> >> COL = T.A.plus(T.B).parenthesis().multiplyWith(2.0);
> >>
> >> would be the solutions you are looking for.
> >>
> >> Regards
> >> Rainer
> >>
> >>
> >> > from: Ivan Nemeth [mailto:ivan.nem...@gmail.com]
> >> > to: dev@empire-db.apache.org
> >> > subject: Bug with DBColumnExpr.multiplyWith and divide
> >> >
> >> > Hi,
> >> >
> >> > (Rainer, couldn't create an issue in Jira, please can you check it?
> >> (missing
> >> > permission maybe?))
> >> >
> >> > Empire generates wrong sql if you multiply a DBCalcExpr with some
> value,
> >> > example:
> >> >
> >> > DBDatabase db = new DBDatabase() {
> >> > };
> >> > db.open(new DBDatabaseDriverHSql(), null); class Test extends DBTable
> {
> >> >
> >> > final DBTableColumn A;
> >> > final DBTableColumn B;
> >> > public Test(String name, DBDatabase db) { super(name, db); A =
> >> > addColumn("A", DataType.INTEGER, 64, true); B = addColumn("B",
> >> > DataType.INTEGER, 64, true); } }
> >> >
> >> > Test T = new Test("test", db);
> >> > DBCommand cmd = db.createCommand();
> >> > *DBColumnExpr COL = T.A.plus(T.B).multiplyWith(2.0);*
> >> >
> >> > cmd.select(COL);
> >> >
> >> > System.out.println(cmd.getSelect());
> >> >
> >> > The expected sql would be:
> >> >
> >> > *SELECT (t1.A + t1.B) * 2.0 FROM test t1*
> >> >
> >> > but Empire generates it with no parentheses
> >> >
> >> > *SELECT t1.A + t1.B * 2.0 FROM test t1*
> >> >
> >> > Solution would be to append parentheses in DBCalcExpr.addSql method
> >> > something like this (it is required only for * and / operators):
> >> >
> >> > *buf.append("(");*
> >> > expr.addSQL(buf, context);
> >> > *buf.append(")");  *
> >> > buf.append(op);
> >> > // Special treatment for adding days to dates ...
> >> >
> >> > What do you think?
> >> >
> >> >
> >> > Regards,
> >> > Ivan
> >>
> >


Re: Proposal: Extending DBCommand with "insertOrUpdate" ("UPSERT")

2016-08-14 Thread ivan nemeth
Hi,

I think the problem is more complicated than just naming the method.

Take my previous example, with a small change, and define a UNIQUE
constraint on the NAME column.

ID NAME

1 A
2 B

After executing this command:

DBCommand cmd = db.createCommand();
cmd.set(T.ID.to <http://db.upsert_test.id.to/>(3));
cmd.set(T.NAME.to <http://db.upsert_test.name.to/>("A"));
db.executeInsertOrUpdate(cmd, conn);

the result will be:

ID NAME

3 A
2 B

To achieve the same result with the fallback method, one has to add the
following constraint

cmd.where(T.ID.is(3).or(T.NAME.is("A")));



Although it would be really a great feature, I see some problems with the
implementation:

1.  I think the main goal of the DBCommand API is that the same code should
do the same thing on every driver. In the example above if you omit the
constraint, MySql implementetion will be ok, but the fallback won't.

2. To achieve the same result, it is required that the coder adds a
constraint which OR's *the PK and all UNIQUE columns* with the
corresponding value in the update statement (this is what MySql actually
does according to the documentation). This may lead a lot of errors if
someone forgets to add a constraint, tests it on MySql and than moves to
other driver.

3. For me the MySql approach that takes into account not only the PK
conflict, but all UQ conflicts, is a bit strange. I don't know how other
coders think about it, but for me in OOP a record is identified in the
table with it's PK. So in the example above I would expect insertOrUpdate
to throw a duplicate key exception, and not updating the PK of the first
row. I think this is inconsistent with an object oriented approach, as in
this case an object disappears from the db after a simple update or insert
operation. Maybe this behaviour is self-evident for MySql programmers, but
for me it's not.




Regards,
Ivan




Rainer Döbele <doeb...@esteam.de> ezt írta (időpont: 2016. aug. 12., P,
11:56):

> IMO updateOrInsert is what we want, just from the plain understanding of
> the name.
>
> Rainer
>
>
> > from: j...@glaubitz.org [mailto:j...@glaubitz.org]
> > to: dev@empire-db.apache.org
> > subject: Re: Proposal: Extending DBCommand with "insertOrUpdate"
> > ("UPSERT")
> >
> > Hello Ivan,
> >
> > thanks for testing.
> >
> > I think youre right - its a little bit confusing. For me it was always
> clear I need
> > to add a WHERE-clause because, I wanted to do an update, if that "fails"
> (as
> > in "nothing updated"), an INSERT. MySQL uses an INSERT as initial
> statement,
> > so I called the new methods "insertOrUpdate"
> > instead of "updateOrInsert". Maybe thats the point. Do you think its more
> > clear that you have to define a WHERE, if the method was called
> > "updateOrInsert"?
> >
> > - jan
> >
> > Am 2016-08-11 19:43, schrieb ivan nemeth:
> > > Hi Jan,
> > >
> > > I've tested it on MySql and I have one problem with it.
> > >
> > > 1. The insertOrUpdate doesn't do the same as the fallback method in
> > > case of an update and if I don't define any where conditions.
> > >
> > > I have a table, with columns ID (PK) and NAME and the following
> > > initial values.
> > >
> > > ID NAME
> > > 
> > > 1 A
> > > 2 B
> > >
> > > *1. InsertOrUpdate*
> > >
> > >
> > > DBCommand cmd = db.createCommand();
> > > cmd.set(T.ID.to <http://db.UPSERT_TEST.ID.to>(2));
> > > cmd.set(T.NAME.to <http://db.UPSERT_TEST.NAME.to>("C"));
> > > db.executeInsertOrUpdate(cmd, conn);
> > >
> > > After executing it, the table looks OK:
> > >
> > > ID NAME
> > > 
> > > 1 A
> > > 2 C
> > >
> > > *2. Fallback => try update, then insert*
> > >
> > > cmd.set(T.ID.to <http://db.UPSERT_TEST.ID.to>(2));
> > > cmd.set(T.NAME.to <http://db.UPSERT_TEST.NAME.to>("C"));
> > > int count = db.executeUpdate(cmd, conn); if (count < 1) { count +=
> > > db.executeInsert(cmd, conn); }
> > >
> > > This throws a Duplicate key exception in the executeUpdate() method,
> > > because it tries to update ALL records (there is no update condition
> > > defined).
> > > If I add the condition cmd.where(T.ID.i
> > > <http://db.upsert_test.name.to/>s(2),
> > > it's OK, but I think it's problematic that insertOrUpdate behaves
> > > differently with different drivers

Re: Proposal: Extending DBCommand with "insertOrUpdate" ("UPSERT")

2016-08-08 Thread ivan nemeth
Hi Jan,

you're right, it's different, ON UPDATE is a better choice. (We use REPLACE
with tables with no foreign keys on it, so we haven't had any problems with
the delete).


Regards,
Ivan


<j...@glaubitz.org> ezt írta (időpont: 2016. aug. 8., H, 15:22):

> Hello Ivan,
>
> REPLACE INTO is slightly different.
>
> > REPLACE works exactly like INSERT, except that if an old row in the
> > table has the same value as a new row for a PRIMARY KEY or a UNIQUE
> > index, the old row is deleted before the new row is inserted
> > (http://dev.mysql.com/doc/refman/5.7/en/replace.html)
>
> I think (not tested tho) this wont work if you have foreign keys on
> that table. IMO it wont be equivalent to a MERGE implementation in
> Oracle.
>
> - jan
>
> Zitat von Ivan Nemeth <ivan.nem...@gmail.com>:
>
> > Hi Jan,
> >
> > I agree, it would be useful. We also use some insertOrUpdate mechanism,
> > currently implemented as pure SQL, but it would be great if we can do it
> > with Empire.
> > 2 remarks:
> >
> > 1. With MySql we use REPLACE INTO instead ON DUPLICATE..., maybe it's the
> > same.
> > 2. It's also possible with MSSQL using the MERGE command.
> >
> > Regards,
> > Ivan
> >
> >
> >
> >
> > <j...@glaubitz.org> ezt írta (időpont: 2016. aug. 8., H, 13:01):
> >
> >> Hello,
> >>
> >> I'm currently writing a few sync jobs. The naive approach was to run
> >> an UPDATE first and an INSERT with same DBCommand object if nothing
> >> was updated. This works but is slow.
> >>
> >> I figured there is a INSERT ... ON DUPLICATE KEY UPDATE Syntax in
> >> MySQL
> >> (http://dev.mysql.com/doc/refman/5.5/en/insert-on-duplicate.html)
> >> which combines INSERT and UPDATE in one single statement. Using this
> >> I'm able to perform a single batch satement instead of single
> >> statements. In my first try it saved 70 % of running time.
> >>
> >> My implementation is pretty simple, its just
> >>
> >> public synchronized String getInsertOrUpdate()
> >> {
> >> StringBuilder buf = new StringBuilder(getInsert());
> >> buf.append(" ON DUPLICATE KEY UPDATE ");
> >> long context = CTX_NAME | CTX_VALUE;
> >> addListExpr(buf, set, context, ", ");
> >> return buf.toString();
> >> }
> >>
> >> in DBCommandMySQL, but to add this in my DBSQLScript I have to cast my
> >> DBCommand to DBCommandMySQL every time.
> >>
> >> I think we should add a method to do this in DBCommand with a default
> >> implementation that throws a NotSupportedException. Same in DBDatabase
> >> (executeInserOrUpdate(...). IMO this is a good idea because its
> >> possible in Oracle (using MERGE) and at least Postgres
> >> (https://wiki.postgresql.org/wiki/UPSERT) - and is very useful.
> >>
> >> Opinions?
> >>
> >> - jan
> >>
> >>
>
>
>
>


Re: Proposal: Extending DBCommand with "insertOrUpdate" ("UPSERT")

2016-08-08 Thread Ivan Nemeth
Hi Jan,

I agree, it would be useful. We also use some insertOrUpdate mechanism,
currently implemented as pure SQL, but it would be great if we can do it
with Empire.
2 remarks:

1. With MySql we use REPLACE INTO instead ON DUPLICATE..., maybe it's the
same.
2. It's also possible with MSSQL using the MERGE command.

Regards,
Ivan




 ezt írta (időpont: 2016. aug. 8., H, 13:01):

> Hello,
>
> I'm currently writing a few sync jobs. The naive approach was to run
> an UPDATE first and an INSERT with same DBCommand object if nothing
> was updated. This works but is slow.
>
> I figured there is a INSERT ... ON DUPLICATE KEY UPDATE Syntax in
> MySQL
> (http://dev.mysql.com/doc/refman/5.5/en/insert-on-duplicate.html)
> which combines INSERT and UPDATE in one single statement. Using this
> I'm able to perform a single batch satement instead of single
> statements. In my first try it saved 70 % of running time.
>
> My implementation is pretty simple, its just
>
> public synchronized String getInsertOrUpdate()
> {
> StringBuilder buf = new StringBuilder(getInsert());
> buf.append(" ON DUPLICATE KEY UPDATE ");
> long context = CTX_NAME | CTX_VALUE;
> addListExpr(buf, set, context, ", ");
> return buf.toString();
> }
>
> in DBCommandMySQL, but to add this in my DBSQLScript I have to cast my
> DBCommand to DBCommandMySQL every time.
>
> I think we should add a method to do this in DBCommand with a default
> implementation that throws a NotSupportedException. Same in DBDatabase
> (executeInserOrUpdate(...). IMO this is a good idea because its
> possible in Oracle (using MERGE) and at least Postgres
> (https://wiki.postgresql.org/wiki/UPSERT) - and is very useful.
>
> Opinions?
>
> - jan
>
>


Re: DBDatabase.open() question

2015-11-08 Thread ivan nemeth
Hi Rainer,

I've made the changes.

Regards,
Ivan

On Sun, Nov 1, 2015 at 11:23 AM, Rainer Döbele <doeb...@esteam.de> wrote:

> Hi Ivan,
>
> there is always room for improvements ;-)
>
> Please create an issue in Jira and change the code as desired.
> Please make sure, that the code is properly tested.
>
> Regards,
> Rainer
>
> > -Ursprüngliche Nachricht-
> > from: ivan.nem...@gmail.com [mailto:ivan.nem...@gmail.com]
> > to: dev@empire-db.apache.org
> > re: Re: DBDatabase.open() question
> >
> > Hi Rainer,
> >
> > thanks for your answer.
> >
> > For the SET DATEFORMAT sql: wouldn't be better to handle it with
> > SQL_DATE_TEMPATE and SQL_DATETIME_TEMPLATE like in Oracle driver?
> >
> > I mean something like this in DBDatabaseDriverMSSQL.getSqlPhrase():
> >
> > case SQL_DATE_TEMPLATE:   return "convert(date, '{0}', 121)";
> > case SQL_DATETIME_TEMPLATE:   return "convert(datetime, '{0}', 121)";
> >
> >
> > Regards,
> > Ivan
> >
> > On Sat, Oct 31, 2015 at 9:51 AM, Rainer Döbele <doeb...@esteam.de>
> > wrote:
> >
> > > Hi Ivan,
> > >
> > > I can say for SQL-Server that there is a default schema but this might
> > > not necessarily be the database schema you want to work with.
> > > Hence you need to select the database using USE [xyz] in order to
> > > access the correct database schema.
> > > This might not be necessary if the default schema for the connecting
> > > user has already been set correctly.
> > >
> > > Also the date format is set to make sure, that the order of day, month
> > > and year corresponds to our internal representation, in case it
> differs.
> > >
> > > This needs to be done for every connection unless you can make sure,
> > > that the connections already has all required settings.
> > > So the best way would be to check your user settings in the database
> > > first and check whether when you connect you already access the correct
> > db schema.
> > > If this is the case, then there is no need to execute the statements.
> > >
> > > You might derive your own class from your preferred database driver
> > > and then use this to skip this or implement your own logic.
> > >
> > > Regards,
> > > Rainer
> > >
> > > ---
> > > > from: Ivan Nemeth [mailto:ivan.nem...@gmail.com]
> > > > to: dev@empire-db.apache.org
> > > > re: DBDatabase.open() question
> > > >
> > > > Hi guys,
> > > >
> > > > I have a question about DBDatabase.open() method. It sets the driver
> > > > for
> > > the db and calls the driver's attachDatabase method which in most
> > > cases does nothing . But in case of MSSQL and MySql driver it executes
> > > some initialization SQL (*). We use a connection pool and a singleton
> > > DBDatabase instance, which is opened only once when the app is
> > > initialized. So this initialization script is executed only for the
> first
> > connection.
> > > >
> > > > So what is the purpose of this initialization SQL? Is it necessary,
> > > > and
> > > if yes, in case of a connection pool the DBDatabase should be open for
> > > every new connection?
> > > >
> > > > Regards,
> > > > Ivan
> > > >
> > > > * it sets the database to use (USE DATABASE...) and the date format
> > >
>


Re: DBDatabase.open() question

2015-10-31 Thread ivan nemeth
Hi Rainer,

thanks for your answer.

For the SET DATEFORMAT sql: wouldn't be better to handle it with
SQL_DATE_TEMPATE and SQL_DATETIME_TEMPLATE like in Oracle driver?

I mean something like this in DBDatabaseDriverMSSQL.getSqlPhrase():

case SQL_DATE_TEMPLATE:   return "convert(date, '{0}', 121)";
case SQL_DATETIME_TEMPLATE:   return "convert(datetime, '{0}', 121)";


Regards,
Ivan

On Sat, Oct 31, 2015 at 9:51 AM, Rainer Döbele <doeb...@esteam.de> wrote:

> Hi Ivan,
>
> I can say for SQL-Server that there is a default schema but this might not
> necessarily be the database schema you want to work with.
> Hence you need to select the database using USE [xyz] in order to access
> the correct database schema.
> This might not be necessary if the default schema for the connecting user
> has already been set correctly.
>
> Also the date format is set to make sure, that the order of day, month and
> year corresponds to our internal representation, in case it differs.
>
> This needs to be done for every connection unless you can make sure, that
> the connections already has all required settings.
> So the best way would be to check your user settings in the database first
> and check whether when you connect you already access the correct db schema.
> If this is the case, then there is no need to execute the statements.
>
> You might derive your own class from your preferred database driver and
> then use this to skip this or implement your own logic.
>
> Regards,
> Rainer
>
> ---
> > from: Ivan Nemeth [mailto:ivan.nem...@gmail.com]
> > to: dev@empire-db.apache.org
> > re: DBDatabase.open() question
> >
> > Hi guys,
> >
> > I have a question about DBDatabase.open() method. It sets the driver for
> the db and calls the driver's attachDatabase method which in most cases
> does nothing . But in case of MSSQL and MySql driver it executes some
> initialization SQL (*). We use a connection pool and a singleton DBDatabase
> instance, which is opened only once when the app is initialized. So this
> initialization script is executed only for the first connection.
> >
> > So what is the purpose of this initialization SQL? Is it necessary, and
> if yes, in case of a connection pool the DBDatabase should be open for
> every new connection?
> >
> > Regards,
> > Ivan
> >
> > * it sets the database to use (USE DATABASE...) and the date format
>


DBDatabase.open() question

2015-10-30 Thread Ivan Nemeth
Hi guys,

I have a question about DBDatabase.open() method. It sets the driver for
the db and calls the driver's attachDatabase method which in most cases
does nothing . But in case of MSSQL and MySql driver it executes some
initialization SQL (*). We use a connection pool and a singleton DBDatabase
instance, which is opened only once when the app is initialized. So this
initialization script is executed only for the first connection.

So what is the purpose of this initialization SQL? Is it necessary, and if
yes, in case of a connection pool the DBDatabase should be open for every
new connection?

Regards,
Ivan

* it sets the database to use (USE DATABASE...) and the date format


Re: empire-db git commit: DBRecordCallbackHandler and DBRecordMapper method changed

2015-10-25 Thread Ivan Nemeth
Hi Francis,

all commits in Spring project are related to

https://issues.apache.org/jira/browse/EMPIREDB-227

In the future I will add it to the comments.

Regards,
Ivan


On Sun, Oct 25, 2015 at 8:06 PM, Francis De Brabandere 
wrote:

> Hi guys, would be nice to link commits to a ticket so we can easily create
> a change log on release.
>
> Cheers,
> Francis
>
>
> -- Forwarded message --
> From: 
> Date: 25 October 2015 at 09:48
> Subject: empire-db git commit: DBRecordCallbackHandler and DBRecordMapper
> method changed
> To: comm...@empire-db.apache.org
>
>
> Repository: empire-db
> Updated Branches:
>   refs/heads/master 11ff2d595 -> 7ac3454c4
>
>
> DBRecordCallbackHandler and DBRecordMapper method changed
>
> Project: http://git-wip-us.apache.org/repos/asf/empire-db/repo
> Commit: http://git-wip-us.apache.org/repos/asf/empire-db/commit/7ac3454c
> Tree: http://git-wip-us.apache.org/repos/asf/empire-db/tree/7ac3454c
> Diff: http://git-wip-us.apache.org/repos/asf/empire-db/diff/7ac3454c
>
> Branch: refs/heads/master
> Commit: 7ac3454c455da17b01b562946d5986c2ffeb222f
> Parents: 11ff2d5
> Author: inemeth 
> Authored: Sun Oct 25 09:43:59 2015 +0100
> Committer: inemeth 
> Committed: Sun Oct 25 09:43:59 2015 +0100
>
> --
>  .../apache/empire/spring/DBRecordCallbackHandler.java |  2 +-
>  .../java/org/apache/empire/spring/DBRecordMapper.java |  4 +++-
>  .../java/org/apache/empire/spring/EmpireTemplate.java | 14 --
>  .../apache/empire/spring/example1/EmpireAppImpl.java  | 10 +-
>  .../empire/spring/example2/EmployeeDaoImpl.java   | 10 +-
>  5 files changed, 22 insertions(+), 18 deletions(-)
> --
>
>
>
> http://git-wip-us.apache.org/repos/asf/empire-db/blob/7ac3454c/empire-db-spring/src/main/java/org/apache/empire/spring/DBRecordCallbackHandler.java
> --
> diff --git
>
> a/empire-db-spring/src/main/java/org/apache/empire/spring/DBRecordCallbackHandler.java
>
> b/empire-db-spring/src/main/java/org/apache/empire/spring/DBRecordCallbackHandler.java
> index aa0a318..8484299 100644
> ---
>
> a/empire-db-spring/src/main/java/org/apache/empire/spring/DBRecordCallbackHandler.java
> +++
>
> b/empire-db-spring/src/main/java/org/apache/empire/spring/DBRecordCallbackHandler.java
> @@ -39,6 +39,6 @@ public interface DBRecordCallbackHandler {
>  * @param record
>  */
>
> -   void processRow(DBRecordData record);
> +   void processRecord(DBRecordData record);
>
>  }
>
>
> http://git-wip-us.apache.org/repos/asf/empire-db/blob/7ac3454c/empire-db-spring/src/main/java/org/apache/empire/spring/DBRecordMapper.java
> --
> diff --git
>
> a/empire-db-spring/src/main/java/org/apache/empire/spring/DBRecordMapper.java
>
> b/empire-db-spring/src/main/java/org/apache/empire/spring/DBRecordMapper.java
> index 1a58bc6..6820eca 100644
> ---
>
> a/empire-db-spring/src/main/java/org/apache/empire/spring/DBRecordMapper.java
> +++
>
> b/empire-db-spring/src/main/java/org/apache/empire/spring/DBRecordMapper.java
> @@ -39,9 +39,11 @@ public interface DBRecordMapper {
>  *
>  * @param record
>  *the DBRecordData to map
> +* @param rowNum
> +*the number of the current row
>  * @return the result object
>  */
>
> -   public abstract K read(DBRecordData record);
> +   public abstract K mapRecord(DBRecordData record, int rowNum);
>
>  }
>
>
> http://git-wip-us.apache.org/repos/asf/empire-db/blob/7ac3454c/empire-db-spring/src/main/java/org/apache/empire/spring/EmpireTemplate.java
> --
> diff --git
>
> a/empire-db-spring/src/main/java/org/apache/empire/spring/EmpireTemplate.java
>
> b/empire-db-spring/src/main/java/org/apache/empire/spring/EmpireTemplate.java
> index a0fac01..ddf3301 100644
> ---
>
> a/empire-db-spring/src/main/java/org/apache/empire/spring/EmpireTemplate.java
> +++
>
> b/empire-db-spring/src/main/java/org/apache/empire/spring/EmpireTemplate.java
> @@ -231,7 +231,7 @@ public class EmpireTemplate implements InitializingBean
> {
> class SingleValueMapper implements DBRecordMapper {
>
> @Override
> -   public Object read(DBRecordData record) {
> +   public Object mapRecord(DBRecordData record, int
> rowNum) {
> return record.getValue(col);
> }
>
> @@ -277,7 +277,7 @@ public class EmpireTemplate implements InitializingBean
> {
> class SingleLongMapper implements DBRecordMapper {
>
> @Override
> -