Thanks Lukas. Things are clear now
> -Original Message-
> From: Lukas Eder [mailto:lukas.e...@gmail.com]
> Sent: Thursday, December 05, 2013 7:05 AM
> To: dev@cloudstack.apache.org
> Subject: Re: persistence layer
>
> Hello,
>
> From the follow-up posts on
teria built on JPA:
> > > Qeury q = new Qeury();
> > > q.add(Book_.PublishedIn. Op.eq, 2011); q.orderBy(Book_.title);
> > > List books = q.list();
> > >
> > > The last way is more Java for sure, people who even has no SQL
> > > knowledge can wr
ery(agnostic to underlying DB) would be enough for most of
persistence needs in CloudStack.
>
>
>
>> -Original Message-
>> From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com]
>> Sent: Monday, December 02, 2013 9:33 AM
>> To: dev@cloudstack.apache.org
>&
Hello Darren,
I'm reading your reply - I shall post comments when I've got through it
completely.
-Original Message-
From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com]
Sent: 02 December 2013 17:33
To: dev@cloudstack.apache.org
Subject: Re: persistence layer
Alrigh
t;
>>> > == persistence ===
>>> > create.insertInto(AUTHOR)
>>> > .set(AUTHOR.ID, 100)
>>> > .set(AUTHOR.FIRST_NAME, "Hermann")
>>> > .set(AUTHOR.LAST_NAME, "Hesse")
>>> > .newRecord()
>>>
riteria built on JPA:
>> > Qeury q = new Qeury();
>> > q.add(Book_.PublishedIn. Op.eq, 2011); q.orderBy(Book_.title);
>> > List books = q.list();
>> >
>> > The last way is more Java for sure, people who even has no SQL
>> > knowledge can write the search
te a query criteria or
JOOQ fluent query on demand.
> -Original Message-
> From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com]
> Sent: Monday, December 02, 2013 9:33 AM
> To: dev@cloudstack.apache.org
> Subject: Re: persistence layer
>
> Alright, this is long..
&g
.from(AUTHOR)
> > .join(BOOK).on(BOOK.AUTHOR_ID.equal(AUTHOR.ID))
> > .where(BOOK.LANGUAGE.equal("DE"))
> > .and(BOOK.PUBLISHED.greaterThan("2008-01-01"))
> > .groupBy(AUTHOR.FIRST_NAME, AUTHOR.LAST_NAME)
> > .having(co
ME, AUTHOR.LAST_NAME, count())
> > .from(AUTHOR)
> > .join(BOOK).on(BOOK.AUTHOR_ID.equal(AUTHOR.ID))
> > .where(BOOK.LANGUAGE.equal("DE"))
> > .and(BOOK.PUBLISHED.greaterThan("2008-01-01"))
> > .groupBy(AUTHOR.FIRST_NAME,
lopers are
> used to static type too much, they are not willing
> to write any code that cannot be checked by compiler. Type safe is the
> reason that no ORM is perfect, and it can never be.
>
> In summary, I don't think dropping in any ORM can solve problem perfectly,
>
ge-
> From: Lukas Eder [mailto:lukas.e...@gmail.com]
> Sent: Tuesday, November 26, 2013 3:58 AM
> To: dev@cloudstack.apache.org
> Subject: Re: persistence layer
>
> Dear CloudStack developers,
>
> This thread has caught my attention and I thought I might chime in and
Hi Lukas, thanks for chiming in.
I do agree that abstracting over NoSQL and SQL is not compelling.
Both have their specific strengths and developers would be foolhardy to
simply assume that swapping one for the other will magically work.
On 11/26/13 3:57 AM, "Lukas Eder" wrote:
>Dear CloudStack
Dear CloudStack developers,
This thread has caught my attention and I thought I might chime in and give
you some background information about jOOQ, JDBC, RDBMS in general (I work
for Data Geekery, the company behind jOOQ). I've already had the pleasure
to talk to Darren on the jOOQ User Group and
bout stuff like derby or sqlserver or
oracle or db2.
--Alex
> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com]
> Sent: Monday, November 25, 2013 2:21 AM
> To: dev@cloudstack.apache.org
> Subject: Re: persistence layer
>
>
> On Nov 23, 2013, a
MariaDB is a drop in replacement for MySQL, so it can be used with or without
the JOOQ changes.
Travis
On Nov 25, 2013, at 5:20 AM, Sebastien Goasguen wrote:
>
> On Nov 23, 2013, at 4:13 PM, Laszlo Hornyak wrote:
>
>> Wouldn't it be a lot of work to move to JOOQ? All queries will have to be
On Nov 23, 2013, at 4:13 PM, Laszlo Hornyak wrote:
> Wouldn't it be a lot of work to move to JOOQ? All queries will have to be
> rewritten.
>
>
An a non-java developer question: Will that help support different databases ?
like moving to MariaDB ?
>
> On Sat, Nov 23, 2013 at 11:32 AM, Darr
Wouldn't it be a lot of work to move to JOOQ? All queries will have to be
rewritten.
On Sat, Nov 23, 2013 at 11:32 AM, Darren Shepherd <
darren.s.sheph...@gmail.com> wrote:
> Going to an ORM is not as simple as you would expect. First, one can make
> a strong argument that ORM is not the right
Going to an ORM is not as simple as you would expect. First, one can make a
strong argument that ORM is not the right solution, but that can be ignored
right now.
You have to look at the context of ACS and figure out what technology is the
most practical to adopt. ACS does not have ORM toda
Jooq does a good job of handling the differences in dialects so as long as you
don't use a feature specific to a database your are fine. More info at
http://www.jooq.org/doc/3.2/manual/sql-building/dsl-context/sql-dialects/
I've used jooq across databases and it's been fine. The sql we use in
-Original Message-
> From: Alex Ough [mailto:alex.o...@sungard.com]
> Sent: Friday, November 22, 2013 9:50 AM
> To: dev@cloudstack.apache.org
> Subject: Re: persistence layer
>
> All,
>
> I'm very interested in converting the current DAO framework to an ORM
All,
I'm very interested in converting the current DAO framework to an ORM. I
didn't have any experience with java related ORMs, but I've done quite lots
of works with Django and LINQ. So can you add me if this project is started?
Thanks
Alex Ough
On Fri, Nov 22, 2013 at 7:06 AM, Daan Hoogland
Had a quick look, It looks alright. One question/doubt: will we thigh
ourselves more to mysql if we code sql more directly instead of
abstracting away from it so we can leave db choice to the operator in
the future!?!?
On Thu, Nov 21, 2013 at 7:03 AM, Darren Shepherd
wrote:
> I've done a lot of a
I've done a lot of analysis on the data access layer, but just haven't had time
to put together a discuss/recommendation. In the end I'd propose we move to
jOOQ. It's an excellent framework that will be very natural to the style of
data access that CloudStack uses and we can slowly migrate to
23 matches
Mail list logo
