Hi Thorsten, That's a very interesting setup, thanks for sharing. MBs of RAM. Reminds me of my first days with software / computers, on an 80286 with a whopping 4MB of RAM (and tens of MB of disk space!)
I can't give you any user insight on your questions, although, you might find some interesting insight and power user feedback regarding your third question about jOOQ with GraalVM here: https://github.com/quarkusio/quarkus/issues/7440 and here: https://github.com/jOOQ/jOOQ/issues/8779 Using jOOQ on such low profile hardware is a bit of a risk. For a few reasons: - jOOQ's DSL isn't very small in terms of byte code size. You might be able to reduce it using something like Proguard, throwing out unnecessary stuff. A future jOOQ-lite distribution might be helpful, too: https://github.com/jOOQ/jOOQ/issues/8928. But vanilla jOOQ seems to be quite heavy for this environment - The runtime overhead of building *every* query dynamically might be too much. Our benchmarks hint at the StringBuilder effort being the biggest remaining bottleneck within jOOQ (if you ignore the much bigger work of the JDBC driver, execution planner, I/O, etc.). We have plans to migrate towards more immutability, and thus better possible caching of de-facto static SQL queries. But until then, keep in mind that currently, all jOOQ queries are constructed dynamically at runtime. You could obviously build a cache yourself, where a jOOQ query produces its SQL only once for the lifecycle of your application. Something like this: https://github.com/jOOQ/jOOQ/issues/8320 However, I think your setup is special, because you want to re-use your jOOQ-based code base between environments where jOOQ shines (your server), and where jOOQ is not yet as efficient as it could be. It would be interesting to be able to construct jOOQ queries either on this server, and then ship the query strings to your ARM-based environment (I'm aware of a customer who does this, for entirely different reasons), or use some way generate jOOQ queries at build-time, shipping the SQL statements in a file. In fact, I have thought about offering such tooling in the past. It would be really interesting to do all the SQL generation work at compile time, and then produce type safe JDBC (or R2DBC, etc.) wrapping logic, including the logic that maps query results to POJOs. Perhaps something similar to SQLDelight, but more powerful. Would that be something like what you had in mind? Cheers, Lukas On Sat, Oct 3, 2020 at 10:56 AM Thorsten Schöning <[email protected]> wrote: > Hi all, > > TL;DR: > > Does anyone use jOOQ in some embedded IoT-context with ARM-based > hardware and only few MiBs of RAM at all? > > Does anyone use jOOQ with e.g. Postgres/Oracle/... on some high > resources server and mostly the same codebase in somer lower resources > setup using less RAM, CPU-power and e.g. SQLite? > > Does anyone use jOOQ with GraalVM and native images? > > Thanks for your experiences! > > Background: > > I'm planning some special gateway to receive, store and forward > telegrams from various different smart meters[1]. Such a gateway > exists already and has proven to be somewhat limited, so "simply" > should be replaced with a version 2, doing conceptually the same > things, but with fewer technical restrictions. > > The important thing to note is that I already have the server to which > version 1 of the gateway is sending telegrams right now. This means I'm > already able to store, parse, process etc. those telegrams in various > ways on the server and many of those things will exactly be needed the > same for version 2 of the gateway. > > The important difference of course is resources: The server has > multiple CPUs and GiBs of RAM, while the new gateway is some ARM-based > thing with only 256 MiB of RAM currently. To make things even more > complicated, one version of that gateway might(!) be powerd by > battery only. > > Nevertheless, reusing as much of the already available code base seems > to be abig benefit to me, to especially not need to develop the same > complex business logic multiple times. I've already put my server with > Tomcat and stuff 1:1 on some Raspi and things worked flawlessly as > expected, only the RAM-limit became a problem. And that's where > GraalVM native images and other downstripping becomes interesting. > > [1]: https://en.wikipedia.org/wiki/Smart_meter > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning E-Mail: [email protected] > AM-SoFT IT-Systeme http://www.AM-SoFT.de/ > > Telefon...........05151- 9468- 55 > Fax...............05151- 9468- 88 > Mobil..............0178-8 9468- 04 > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow > > -- > You received this message because you are subscribed to the Google Groups > "jOOQ User Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jooq-user/51732650.20201003105555%40am-soft.de > . > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/CAB4ELO6T4vpey1cen%3DnLRidtu%3DC056vneiBRtMerKa5uxWtBaA%40mail.gmail.com.
