Are there any plans to add an object query language to LLBLGen? I find the current method of filtering and sorting to be adequate, but any time I need to do a more complicated query, I always have to go back to the documentation. I just think a language similar to what Hibernate has would help simplify things for me (see http://www.hibernate.org/hib_docs/reference/en/html/queryhql.html).

Yes a textual query language which is used to produce predicate objects is planned for release later this year. No release date is set, nor which syntax will be used.

After that, can you create a data-storage service layer to eliminate the need for a relational DB? We'll just load the entire shema of entities into memory on the server and use your new query language...

I'll keep dreaming....

Agreed, combined with prefetch path specifications it can make for some ugly code.

I have a rough human readable xml serialiser/deserialser for relationpredicatebuckets that I am working on. It works well enough for my purposes but isn't releasable.

Combined with a graphical query building tool it would be pretty damn handy. Have been messing around with the netron library to visualise relationpredicatebuckets.

Otis wrote:

Yes a textual query language which is used to produce predicate objects is planned for release later this year. No release date is set, nor which syntax will be used.

I stumbled upon this thread.. has this feature been dropped from the roadmap?

What I am actually looking for is a way for applications end users to define their own searches (like in TFS for example).

acradyn wrote:

After that, can you create a data-storage service layer to eliminate the need for a relational DB? We'll just load the entire shema of entities into memory on the server and use your new query language...

I'll keep dreaming....

There are some attempts like this (Bamboo http://bbooprevalence.sourceforge.net/) and AFAIK it is called object prevalence engine. However, I think that no sane person will leave well proven etc. relational databases.

A textual language was planned, but we've opted for operator overloading instead, which preserved the strong-typed query building feature and didn't require a textparser for queries.

Otis wrote:

A textual language was planned, but we've opted for operator overloading instead, which preserved the strong-typed query building feature and didn't require a textparser for queries.

Certainly a good decision.

Otis wrote:

A textual language was planned, but we've opted for operator overloading instead, which preserved the strong-typed query building feature and didn't require a textparser for queries.

Ok. I ended up creating UI for creating predicate expressions. First user defines the criterias, then the UI presentation is transformed to predicate expressions. Works pretty well actually, so far it supports FieldLikePredicate, FieldCompareValuePredicate and FieldCompareRangePredicate (but no subpredicates).

This thread provided some hints too:

http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=332#1464

acradyn wrote:

After that, can you create a data-storage service layer to eliminate the need for a relational DB? We'll just load the entire shema of entities into memory on the server and use your new query language...

I'll keep dreaming....

Or, you can just use Object Prevalence then you don't need a database or a O/R mapping layer.

BOb

pilotboba wrote:

acradyn wrote:

After that, can you create a data-storage service layer to eliminate the need for a relational DB? We'll just load the entire shema of entities into memory on the server and use your new query language...

I'll keep dreaming....

Or, you can just use Object Prevalence then you don't need a database or a O/R mapping layer.

BOb

People said that about XML when it first arrived on the scene. It would replace the relational DB they said. I'm still waiting...