Hey,
Niclas Hedhman a écrit :
> Gang,
> last time I brought up JPA, I think the consensus became; too complex to
> bother. But I think the need for "conventional persistence"
> interoperability is still an issue for us, and I think it should be tackled.
>
> Spring
Thanks a lot Stan for the overview picture, which is sometimes hard to
acquire by looking at the code.
On this topic, there are a few "constraints" that perhaps should be
considered as Core Zest features somehow, that could make life easier when
insisting on RDBMS backing an Zest application.
On 21.9.2016 12:00, Stanislav Muhametsin wrote:
On 21.9.2016 0:08, Jiri Jetmar wrote:
Independently of that that, things starts to be complicated in the SQL
world with large data when you are submitting e.g. a inner JOIN
statement
in a transactional INSERT expression, where the tables are
On 21.9.2016 0:08, Jiri Jetmar wrote:
Independently of that that, things starts to be complicated in the SQL
world with large data when you are submitting e.g. a inner JOIN statement
in a transactional INSERT expression, where the tables are located (the
data) on different nodes, simply because
On 20.9.2016 2:02, Niclas Hedhman wrote:
Right, but with a single JSON column you have reduced RDBMS to a
KeyValue store. Can the JSON document be indexed in some intelligent
way on Postgres?
Jiri managed to reply to this before me. :)
Isn't the SQL EntityStore already doing this in
Right, but with a single JSON column you have reduced RDBMS to a KeyValue
store. Can the JSON document be indexed in some intelligent way on Postgres?
Isn't the SQL EntityStore already doing this in Zest?
Love your; "YesSQL"
Although I saw another funny meme;l
NoSQL 2005 = No freaking SQL
On 19.9.2016 4:40, Niclas Hedhman wrote:
I agree that there is always a schema, and I don't think that anyone really
disagrees with that. It is more a matter of "rigid" or "flexible" schema.
The "rigid" world requires more process overhead to create and evolve, and
over time end up with 500
Good thoughts I think it is a long path forward, and looking at JPA
"fragility" and I now doubt it is doable. With fragility, I mean how
sensitive JPA applications are to the execution model of JPA itself. Since
we don't follow that, I doubt we can make it work reliably.
In rega
Hi guys,
some lines on this JPA / Zest from me.
The requirement to be able to use JPA on Zest has from my perspective three
reasons:
1) Standardized, aka "JPA-way" to persist and query Entities (persistent
Objects with Identities)
2) Be able to use a (relational-) schema tha
s ago.
> I provided the SQL ES with a Connection that would delegate to a XA
> Connection and avoid committing, letting the responsibility to commit to
> the application server.
> It's working in production since then. But it's nasty and I've been lucky,
> especially because of the presence
an Indexer in that
application
One simple way to look at JPA integration would be to simply use Zest
without using its persistence related features.
i.e. "if you use JPA, you don't need (cough!) Zest persistance"
For this we could do various things to ease users pain:
- show (sample, doc, w
I just came across something that has been discussed several times in the
past. It is a anser on [1]
When I read through the Qi4j in 2 minutes, 10 minutes etc. tutorials (the
last one is incomplete), the one obvious question that came to mind was how
do I integrate this with JPA/Hibernate
12 matches
Mail list logo
