Removing the direct in-memory MetaStore should help with refactoring the "persistent" impl. code later, I hope.... mainly because it reduces the amount of work to be done in supporting alternatives.
On Tue, Jan 14, 2025 at 10:55 AM Alex Dutra <alex.du...@dremio.com.invalid> wrote: > Hi all, > > I think Dmitri's suggestion makes sense as a short-term solution. Removing > EclipseLink is a much bigger task, and I don't think we'll have time to do > that before the 1.0.0 release. Imho the 1.0.0 release will ship with > Quarkus + EclipseLink. > > Thanks, > Alex > > On Tue, Jan 14, 2025 at 4:25 PM Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > > > Hi Dmitri > > > > That's a fair question. I agree about H2, but I'm not sure about > > EclipseLink, especially now that we are powered by Quarkus. > > > > Why not directly using JDBC (without EclipseLink) ? > > Quarkus Panache is not really an option for now due to license issue > > (Hibernate ORM). > > > > Regards > > JB > > > > On Tue, Jan 14, 2025 at 4:12 PM Dmitri Bourlatchkov <di...@apache.org> > > wrote: > > > > > > Hi All, > > > > > > Given that it is possible to run EclipseLink with H2 in memory, is > there > > > value in keeping a separate in-memory MetaStore implementation? > > > > > > My main concern is that the plain in-memory MetaStore is significantly > > > different from the EclipseLink metastore and might deviate in > behaviour. > > > With that in mind and given that the plain in-memory impl. is not > > suitable > > > for production use cases, is it worth keeping it? WDYT? > > > > > > Thanks, > > > Dmitri. > > >
