by Rob 26 Aug 10:48
API changes... post 0.9.3

In a good news/bad news way the API is likely to change shortly... Mostly to accommodate a Query object for generics support and better query control. Specifically controlling exactly which properties you wish to fetch (with the rest lazy loading on demand like reference objects).

AKA: For the next major release the features to add are currently...

- Support for fetching only the properties you wish (lazy loading the rest on demand)
- Support for a query language
- new Query object supporting generics (on findList, findMap, findSet)

22 Sep 00:04
by Rob

The query support for partial objects is working well... the downside is that there does not yet seem an equivalent in JPA QL yet. This means I'm likely to use a different QL syntax which is disappointing - however, there are a few significant upsides I can see (in having a more Object graph QL syntax than JPA QL).

An example using the syntax I am working with looks like...

find order (id, orderDate)
join customer (name)
join customer.shippingAddress (*)
join details (*)
join details.product (name)

... which explicitly specifies the properties to include in the query. Note that the ID property is always included automatically. In the example above only the product Id and name is in the product object.

This has potential for adding node by node features such as, fetching a node from cache rather than the DB, specifying a node to be read only etc.

All feedback welcome... thanks, Rob.

30 Oct 11:10
by johan

Hi Rob,

this looks very promising, when can we expect a new release or a snapshot :-)

Regards,
Johan

06 Dec 01:07
by Rob

Sorry for the delay...

0.9.4 should be out in a few days... 11th Dec in my plan. I have been doing some javadoc and testing... its looking good.

0.9.4 should be compatible with 0.9.3 but 0.9.4 deprecates the Find objects, Lookup objects and currently I'd like to change the name of MapBean and UpdateSql to SqlRow and SqlUpdate respectively. This is going to be a PITA for some ... but in my opinion good for the long term look of the API (Making it easier for people to see the 'Relational' part of the API - SqlQuery, SqlRow, SqlUpdate).

If anyone has thoughts I'm keen to hear them. Even if its just to let me know that you are happy with the API changes mooted. I'm also going to get a list of people who want to be notified or participate in questions of API design.

I'll try to make API changes clear on the download page so people are aware of the changes associated with 0.9.4 and 0.9.5 and the intentions.

Feel free to e mail rbygrave at yahoo dot com.

07 Dec 12:14
by christian

Hi Rob, this sounds great. Generics support is really welcome, as well as even lazier loading.

I see you are still using the MapBeans for results. While that works well, isn't it possible to map MapBeans automatically to @Entity objects? (or maybe another or extra annotation for those beans like @QueryResult). After all, all the data is there in the bean on how to map the results. It would also be very nice to be able to predefine queries just once, instead of having to create new instances with a constant string. This would also make it possible to reuse and/or preconfigure them.

I've been brainstorming a bit about this, maybe you can use it. Please don't trip over the syntax, it's more about the idea.

The most transparant way for this to work, is if a query result entity is defined just like a normal table entity. It would need some added annotation. I was thinking in the line of:

@Entity
@QueryResult(query="find order(id) join customer(name) where customer.birthdate after :birthDate limit 10")
public class ReportLine {
int id;
@Column(name="name") String customerName;
}

The user could then fetch it like any other object, but using properties instead. For instance:

List ReportLine report = EBeans.find(ReportLine.class, birthDate [, ... , ... ]);

Or, to set named properties, the user would have to fetch the queryproperties first and set them:

QueryProperties props = Report.newParams();
params.add("birthDate", birthDate)
params.add ... etc
List ReportLine report = EBeans.find(ReportLine.class, params);

or, shorthand:

List ReportLine report = EBeans.find(ReportLine.class, Report.newParams().add("birthDate", birthDate));

As you see I separated the query properties from the query, so the query itself can remain static and final. The nice thing about this is that you can also specify your own property setter this way and enforce that queries can not be passed non existing or bad parameters, and the whole thing also becomes more refactorable. I imagine something like this:

@Entity
@QueryResult ReportQueryProps (query="find order(id) join customer(name) where customer.birthdate after :birthDate limit 10")
public class ReportLine {
int id;
@Column(name="name") String customerName;
}

public class ReportQueryProps extends QueryProperties {

public boolean isValid() {
// can add more checks
return get("birthDate") != null;
}

public ReportQueryProps setCustomer(Customer cust) {
add("birthDate", cust.getBirthDate());
// ... etc
}
}

Now a query can be done like this:

List ReportLine report = EBeans.find(ReportLine.class, Report.newParams().setCustomer(customer));


Damn I really spilled my brains here, but, you asked for it ;-) Hope it helps!


Best regards,

Christian

07 Dec 12:17
by christian

seems your forum filtered out all my less than greater than signs, so no generics show. I'll just mail the original text to you as well Rob.

Regards,

Christian

10 Dec 00:40
by Rob

Christian,

Lots of good ideas in there...

RE: Mapping MapBeans to @Entity objects...
I have thoughts that a developer can create a raw SQL query, and map that to an @Entity bean. This raw SQL would likely end up in the orm.xml file as annotations are not well suited IMO to large (real world) SQL. Perhaps the query could be 'marked' so that it is always used as the 'default' query to use (rather than generated SQL etc).

Roughly getting back to QueryResult, that query could be SQL, or Ebean's query language (or ultimately JPAQL). My gut instinct is that once things get to medium complexity they would develop a SQL query, when they are happy with that throw that SQL (plus bind parameters) into a tool (that isn't built yet) and have the tool generate a bean.

I also thought that these 'report entity beans' would be best having getters and not setters (making them more obviously read only type beans).

In regards the query parameters... yes I see where you are going with that. My quick thought would be... what if you add findList() to the Reports object (hiding Ebean altogether). I haven't done anything like that yet... it looks like a good way to tighten up the code that uses named parameters.

Yes... more thinking any playing required :)

10 Dec 00:50
by Rob

Hmmm... a kind of thread safe query binding class...

Create a New Topic

Title:
Body:
 
Introduction User Guide (pdf) Install/Configure Public JavaDoc Whitepapers
General Database Specific Byte Code Deployment Annotations Features
Top Bugs Top Enhancements
woResponse