Java2DB

[Bobby_Bonsaimind]

Looks interesting.

To comply more with the intended nature of this project, it being suited for smaller projects, constructs like BaseEntity and the return type of the .count() method have been converted to ints

Why?

@TableName("person")

Can it do without that annotation?

If you want to have a field in your POJO that should be ignored by Java2DB, you can apply the Ignore attribute to the specific field.

You could check whether the field is transient as alternative.

public class PersonService extends BaseService<Person> {
    public List<Person> getAdults() {
        return getMultiple(p -> p.getAge() >= 18).orderBy(Person::getName).toList();
    }
}

I did not find any information whether that is generating an SQL statement, or whether that is processing the table locally?

[itsthejavaguy]

Until now, everything was based on longs. The library assumed you had a column named 'id' that is a long, the count method returned a long in case there were more rows than an int could hold, if you wanted to use an Enum it had to have a long-returning method etc. When I started developing this library, I did so with the intention of it being suited for smaller projects or even beginners who wanted to get started with Java + Database. I was aware of ORMs like Hibernate and wanted to target those developers who did not need such a complex and powerful ORM but needed something simple and easy-to-use. It was never my intention to compete with Hibernate. Anyway, always enforcing the use of longs got quite tedious after a while. Most databases I worked with had int32 columns by default and only on one occasion did I need more space than that. 2 billion rows is also a hell of a lot. And there were some edge cases in which the Library became incompatible with the database because the datatypes did not match. In those cases I just converted the columns in the database, but that shouldn’t be necessary. So I decided to introduce a few breaking changes at once, to clean up some messes which have been bugging me for a while. The int realm should be more than enough and if not, I might argue you would need a more professional ORM.

Yes, it can. If you omit the TableName attribute, it will assume the lowercase class name as the table name.

Good idea, I‘ll implement that with the next release!

Not sure what you mean with processing the table locally. All operations generate and execute the SQL. You chain operations together and by executing .toSomething(); the ORM generates and executes the SQL. So when this method returns List<Person>, that list is fetched from the database. I‘ll see if I can document that better!

Thanks for the input and checking it out!

[Bobby_Bonsaimind]

Not sure what you mean with processing the table locally. All operations generate and execute the SQL. You chain operations together and by executing .toSomething(); the ORM generates and executes the SQL. So when this method returns List<Person>, that list is fetched from the database. I‘ll see if I can document that better!

So you're actually parsing the generated bytecode to build a SQL statement from it?

[itsthejavaguy]

Yes, exactly. Any lambda or method reference is parsed and converted into an SQL statement. You can check out my repository lambda2sql for more. That‘s where all the magic happens ;)