Ok,

Well. I have been trying to learn your product all this time, and the beta. Now, for the first time I got to Multi-Entity queries in the doc.

So, my question is, ARE YOU #$(#*$!@#( KIDDING?

I have to specify the relations? Doesn't the O/R mapper know all the relationships? That's alot of the point of using it right?

I hope this is changing in 2.0?

BOb

Heh, customer with 2 relations between address: visitingaddress and billingaddress. Now, to effectively do this, you have to specify relations, otherwise how to filter on an address to get the customer?

Also, the relations give you the power to specify aliases as well, join hints etc.

This definitely will stay, other systems with hidden relations all have limitations where they suddenly have to allow you use relations or it's not flexible.

So no I'm not kidding, though, are you?

(and no, it doesn't know all the relations, because there's no central beating core which controls it all and which limits your freedom of using the code... )

And... what if you want to load entity A and want to filter on entity E, but there are 4 different routes from A to E, via various entities.... Which one to pick?

Happy specifying that in other systems.

And.. the purpose of using an O/R mapper is that you can use your db in an OO way, without having to write SQL and the plumbing code. O/R mappers are just plumbing code, instead of writing it yourself, you grab one from the shelve.

Otis wrote:

So no I'm not kidding, though, are you?

Perhaps in some complex join cases I can see needing to specify a buch of extra stuff. But for example:

Get list of Customers that have placed an order for product X

It would be nice to do something like:

IPredicateExpression e = CustomerFields.Orders.Product == "ProductID"

I'm pretty sure I could do a query like that in NHibernate.

Or, perhaps there is a way to do this without creating Relationship objects?

Thanks, BOb

pilotboba wrote:

I'm pretty sure I could do a query like that in NHibernate.

Now he's just trying to pick a fight.

IMHO, it's better to have the functionality with a little more coding work on your part than serious limitations with a little less. Manually creating the relations represents, perhaps, an additional line of code per joined element which is then resusable for all callers. Small price.

That being said, it could be a nice feature that, in cases where there is only one path to the joined element, the relation is optional and created on the fly...

Jeff...

pilotboba wrote:

Otis wrote:

So no I'm not kidding, though, are you?

Perhaps in some complex join cases I can see needing to specify a buch of extra stuff. But for example:

Get list of Customers that have placed an order for product X

It would be nice to do something like:

IPredicateExpression e = CustomerFields.Orders.Product == "ProductID"

Wasn't it you who said 'LESS CODE!' .

I know that would be nice as well, though it's hard to specify multi-path joins this way, specify join specifics and not fall back onto a string based query language which needs parsing, is not compile time checked and requires a live object with all the relations.

I'm pretty sure I could do a query like that in NHibernate.

Could be, but if you make a typo, you'll find out at runtime. Making it available at compile time is harder and will require a lot of more code plus you'll lose flexibility and consistency. I don't like code which requires you to do things completely different when you want to add a second parameter.

Or, perhaps there is a way to do this without creating Relationship objects?

No. You also don't create relations, you add the ones you want to use to the filter. The filter can then be passed on to whatever you want. LLBLGen Pro doesn't use a string based query system which specifies what you want, in LLBLGen Pro you define filters to define which subset you want, as refinement on the full set.

Btw, CustomerFields.Orders.OrderDetails.ProductID==_id; is cool, though it has some problems. 'ProductID' here isn't a field. It's an object which is specially generated to return OrderDetails-product relation + productid as a field, though, how to cram in the other 2 relations? I have no idea.

NickD wrote:

pilotboba wrote:

I'm pretty sure I could do a query like that in NHibernate.

Now he's just trying to pick a fight.

Hey, I didn't say EntityBroker!

BOb