some problems with ORM concept....what do you think?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

For all the ORM i have searched around, I have always found two big problems:

1) To update or delete a set of records you must first bring it to memory.
If you are inside a loop and have to do it n times, then you have to query
this set n times as well. Would be nice if ORM could make it easier (in a
strongly type manner) to call a dynamic query to directly update/delete
records.

2) I have noticed all ORM work with collection as thei return datatype of a
query. Well, you cannot add, delete, replace, or reorder the elements in this
collection...this restrict a lot the way you can work, specially if you are
iterating in a loop and have to make changes to the same table you are
iterating...

What are your opinions about it ?
 
I may have misexposed what I really meant.
I meant all ORM do HAVE these 2 problems below...
Hibernate (which I have already studied) works exaclty this ways, that is,
it has to bring to memory all records it needs to update/delete, and, since
it works with collections, you just cant update/delete any member of this
collection in such a way the collection gets "lost"....
 
Bruce One said:
I may have misexposed what I really meant.
I meant all ORM do HAVE these 2 problems below...
Hibernate (which I have already studied) works exaclty this ways, that is,
it has to bring to memory all records it needs to update/delete, and, since
it works with collections, you just cant update/delete any member of this
collection in such a way the collection gets "lost"....
Click to expand...

No, Hibernate (at least the Java version) does *not* have to fetch
records in order to update/delete them.

See
http://www.hibernate.org/hib_docs/v3/reference/en/html/batch.html#batch
-direct

aka http://tinyurl.com/4kpug

and scroll down to "DML-style operations".
 
Well the example you linked to me works exaclty the way I put there...look at
a piece of the code presented in the page you forward to me...

..................
.................
// TAKE A LOOK AT THE getNamedQuery method. IT RETURNS ALL RECORDS THAT WILL
BE UPDATED....

ScrollableResults customers = session.getNamedQuery("GetCustomers")
.scroll(ScrollMode.FORWARD_ONLY);
while ( customers.next() ) {
Customer customer = (Customer) customers.get(0);
customer.updateStuff(...);
session.update(customer);
}

tx.commit();
session.close();
 
Bruce One said:
Well the example you linked to me works exaclty the way I put there...look at
a piece of the code presented in the page you forward to me...

.................
................
// TAKE A LOOK AT THE getNamedQuery method. IT RETURNS ALL RECORDS THAT WILL
BE UPDATED....

ScrollableResults customers = session.getNamedQuery("GetCustomers")
.scroll(ScrollMode.FORWARD_ONLY);
while ( customers.next() ) {
Customer customer = (Customer) customers.get(0);
customer.updateStuff(...);
session.update(customer);
}

tx.commit();
session.close();
Click to expand...

Please read my post more carefully. You didn't scroll down to the "DML-
style operations" section as I suggested.
 
Bruce said:
For all the ORM i have searched around, I have always found two big
problems:

1) To update or delete a set of records you must first bring it to
memory. If you are inside a loop and have to do it n times, then you
have to query this set n times as well. Would be nice if ORM could
make it easier (in a strongly type manner) to call a dynamic query to
directly update/delete records.
Click to expand...

Not all O/R mappers force that on you. Some, like LLBLGen Pro (which
I'm the lead developer of), offer the ability to update/delete entities
directly in the persistent storage.

The reason why O/R mappers don't offer these query capabilities often
is based on the fact that it would make their internal caches
completely void.
2) I have noticed all ORM work with collection as thei return
datatype of a query. Well, you cannot add, delete, replace, or
reorder the elements in this collection...this restrict a lot the way
you can work, specially if you are iterating in a loop and have to
make changes to the same table you are iterating...
Click to expand...

I'm not sure what your question is, but I don't recognize this
limitation in my work. Which 'ORM' frameworks are you talking about?

Frans


--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
 
Frans,
You mean you would pass a raw sql to your update/delete method? Or is it
done using Dynamic Query? If so, how an Update command like below would be
called in your BusinessLogic, in such a way you can use all Strongly-Typed
fields?

Update Customers
Set CustomerName = "Bruce"
,CustomerAge = 30
WHERE CustomerID = 30
 
Jon, I saw it. But you must agree this is not Dynamic Query, it does not deal
with strongly-typed fields, its just raw sql, as the code extracted from the
Hibernate page (below)...

String hqlUpdate = "update Customer c set c.name = :newName where c.name =
:oldName";
 
Bruce One said:
Jon, I saw it. But you must agree this is not Dynamic Query, it does not deal
with strongly-typed fields, its just raw sql, as the code extracted from the
Hibernate page (below)...

String hqlUpdate = "update Customer c set c.name = :newName where c.name =
:oldName";
Click to expand...

No, it's not just raw SQL. You can use the properties to perform a
path, eg

"delete Customer c where c.address.zipcode = ...."

What else would you want out of ORM when it comes to updating or
deleting?
 
Bruce said:
Frans,
You mean you would pass a raw sql to your update/delete method? Or is
it done using Dynamic Query? If so, how an Update command like below
would be called in your BusinessLogic, in such a way you can use all
Strongly-Typed fields?

Update Customers
Set CustomerName = "Bruce"
,CustomerAge = 30
WHERE CustomerID = 30
Click to expand...

This uses a dummy entity instance to contain the NEW values for the
fields you're going to set. This also means that I can use an
expression.

CustomerEntity customer = new CustomerEntity();
customer.CustomerName = "Bruce";
customer.CustomerAge = 30;
using(DataAccessAdapter adapter = new DataAccessAdapter())
{
adapter.UpdateEntitiesDirectly(customer,
new RelationPredicateBucket(
CustomerFields.CustomerID==30));
}

I also could have increased your age with 10% :) ->

CustomerEntity customer = new CustomerEntity();
customer.CustomerName = "Bruce";
customer.CustomerAge.ExpressionToApply = (
CustomerFields.CustomerAge +
(CustomerFields.CustomerAge * 0.01f));
using(DataAccessAdapter adapter = new DataAccessAdapter())
{
adapter.UpdateEntitiesDirectly(customer,
new RelationPredicateBucket(
CustomerFields.CustomerID==30));
}

All strongly-typed compile time checked code.

FB


--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
 
Well Jon,
Its not 100% dynamic either...since you have to know table field names, as
in "c.name", rather than strongly typed fields that you could access through
intellisense...
 
Bruce One said:
Its not 100% dynamic either...since you have to know table field names, as
in "c.name", rather than strongly typed fields that you could access through
intellisense...
Click to expand...

That's the current state of ORM though - it's no different in the rest
of the querying etc.

It feels like you're desperately trying to find reasons not to use
ORM...
 
Back
Top