[RELEASED] SQLite ORM similiar to entity framework

After working on it for more than 600 hours, last month I finally released the GRU - SQLite ORM and DB repo manager (asset store link)

the official promo video

and the tutorial:

Inspired by microsoft's entity framework, I ended up developing the ORM for SQLite that allows you to code queries using similar syntax.

Who is this asset for?
Anyone who needs fast and easy data persistence solution in their project(s), regardless of its complexity. Be it an inventory system, mobile game that stores user data for future sessions or you just want to be able to save level data - GRU will have you covered!

What makes it different compared to other similar assets?

• It's the only SQLite ORM for Unity (that I know of) that actually supports the usage of foreign keys
• Developer friendly syntax (Linq)
• Code-first approach
• Database repository pattern (keeps the codebase clean)
• Generates all database files, classes and interfaces automatically!
• Powerful editor menu => create your first database in less than a minute
• Allows integration with popular DB editors directly from Unity (see the promo video). For example, SQLite browser and DBschema
• Usage of Entity Framework-like syntax. For example, let's say that you want to fetch all author's books (i.e. a query that will look for an author in the author table and then also fetch all of his books contained in the book table), with GRU that would be a one-liner =>
  Author author = _authorRepository.Get(id_of_author_goes_here).Include(x=>x.Book, _bookRepo);
• Hooking onto its API is a matter of writing a one liner in your Start() method, everything else is handled by the GRU
• Heavily documented (comes with a 20+ page pdf document full of examples and explanations)
• Unit tested => allowing you to extend its features even further

 

I don't want to discourage you but on the other hand, in case you may not be seeing sales going through the roof after you put in so much work, I wanted to provide an explanation ahead of time: ORM is overkill for most game dev scenarios. And where it isn't it's commonly becoming a bottleneck, so devs sometimes roll their own DB, or only use a single table or BLOB, or undo all the ORM stuff and hardcode once the game features have stabilized.

In the first case, devs may be having like 10 tables tops that are essentially lists of data that could as well be edited with a Spreadsheet tool. And because there's so little of it, it gets loaded into memory at launch, and then accessed by array indices. Foreign keys? Complex queries? Not needed, or very little of it, because most of the data isn't intertwined, may not even be connected at all.

In the second case, you'd have to have at least something as complex as an open world RPG if not an MMO. I worked on an RPG and TCG that used a MySQL database, but that got exported to a custom binary format to speed up loading time. That data was defined by the code itself, like you had a class that represented an Item and it had fields for all the columns in the Item table in a 1:1 mapping. So essentially we still only had flat lists of things, and when it came to combining all that, there was a lot of auto-generating code that made a Sword a "Powerful Sword of Freezing +10" by combining a prefix and suffix modifier onto it.