I agree that it has some advantages, like debugging. How about we keep it, but rename its identifier to "test" to clearly specify its intent? It would also align with other "test" components such as the token service and the token broker.
Ideally, we would eventually put all these "test" components in a separate artifact available when debugging and testing, but absent from the final binary release artifacts. Alex On Wed, Jan 15, 2025 at 4:06 AM Michael Collado <collado.m...@gmail.com> wrote: > Personally, I find the current in-memory store invaluable for debugging. > It's really easy to crack open the tree map and see what entities exist > when tracing down a problem. I'd hate for that to go away and rely on H2 or > sqllite or something. > > I also haven't yet heard any user championing EclipseLink as the preferred > RDBMS implementation. Most people have expressed the desire to have a > simpler JDBC-backed implementation and I'm in favor of that as well. If > anyone was really in favor of the EclipseLink implementation, I'd be happy > to keep it, but if no one is really strongly in favor of it, I don't know > why we'd build more on top of it. > > Mike > > On Tue, Jan 14, 2025 at 9:32 AM Eric Maynard <eric.w.mayn...@gmail.com> > wrote: > > > I think providing direct JDBC as an alternative to EclipseLink is > > potentially a good idea. I am concerned about the prospect of totally > > removing the TreeMap implementation and dropping down to only > EclipseLink. > > Michael remarked the other day that you often need >2 implementations > > before an abstraction really has its mettle tested. To that end, I'm wary > > of removing 1/2 implementations at present time while we are trying to > > improve the persistence interface(s). > > > > Also, on a more practical level, the in-memory metastore is quite useful > > for testing and development. > > > > On Tue, Jan 14, 2025 at 9:28 AM Jean-Baptiste Onofré <j...@nanthrax.net> > > wrote: > > > > > I thought we discussed experimenting directly using JDBC (without > > > EclipseLink) and we will decide what's the best option. > > > > > > On Tue, Jan 14, 2025 at 4:53 PM 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. > > > > > > > > > > >
