Ok java bros, is this shit really the means of avoiding SQL ORM persistence once and for all?I've messed with it and seeing some less than consistent/predictable behaviour at times
>>106470401>EclipseStore>EclipseStore is a databaseless Java-native persistence layer for persisting Java objects without object-relational mappings. EclipseStore is the only data storage layer that uses the native Java object model instead of database-specific data structures or formats. It enables storing any Java object graph of any size and complexity ACID-transaction-safe, seamlessly into any binary data storage such as local disk, persistent volumes or cloud object storage such as AWS S3. Micro snapshots of changes to the object graph are regularly saved to the storage. The ACID transaction journal guarantees full consistency. Each snapshot is stored as a bytecode representation of your Java objects appended to the storage using the Eclipse Serializer's highly optimized byte format. Objects are retrieved from the storage and restored in memory, fully automated by just accessing objects in your object graph by calling getters. Lazy-Loading enables running EclipseStore also with low memory cpacity even lower than 1 GB. At system start, only object IDs are loaded into RAM. Related object references (subgraphs) are loaded into memory on-demand only. EclipseStore's philosophy and goal is to extend Java with an ultra-lightweight databaseless Java-native persistence. Using EclipseStore is amazingly easy and convenient and requires only Java knowledge.Hmmmm, this seems interesting.
>>106470498Agreed. I was hoping it'd be a silver bullet. But some of the default behavior is fuct.For example, calling "store" on some of my objects won't walk all the subobjects of members in the reference graph unless I "store" each of them individually, breaking encapsulation :-(Fucking fuct.
bump for fuck ORM
>>106470401relevant to my interestscurrently got a small project using H2, wonder if this will be easy to drop in as a replacement
>>106472157I'm up in the air over it. I'm tinkering around the corners of it and some of it works. Some of the lazy loading of instances from the backing store file is a bit haphazard to get familiar with it.
Weird. The cornerstone of the eclipsestore system doesnt seem to do what it says: when using EmbeddedStorageManager it doesnt walk the object graph on calling EmbeddedStorageManager.storeRoot(). The fucker requires you yourself to walk the graph to store it eg: EmbeddedStorageManager.store(root.getMember())fuct. what is this piece of shit.
>>106470401use case?
>>106472441use case is when you are sick and tired of using ORMs like Hibernate to access an SQL database when you don't need to use a backend SQL database (eg: greenfield project with no legacy SQL backend to wrap). Instead, persist the object graph directory AND perform queries using Java streams API instead of messy SQL.
>>106472425Well, that's gay. Pretty much indicative of actual faggots involved in Eclipse Modelling. Contrived bullshit
>>106472425Figured it out. Eager saving/loading instances consisting the reference graph doesn't behave by default as theybpromisevin their sales pitch. ONLY if you explicitly configure for EAGER loading/saving. Can be done on a per fi we ld basis
>>106470498Sounds like street shitter tech.
>>106474922Worse. It's part of the Eclipse foundation, the people that brought you EMF. Okay, they're white, but they are all actual faggots in the same way troons infiltrated the entire C++ dev committee.
>>106472463until you need to migrate data or build reporting, then you are screwed
>>106474922last time i looked at the implementation, i stepped through at least ten layers of useless abstraction until anything happened. typical "i imagine a problem to solve, making up the requirements as i go" bullshit
