removal of foreign auto refresh feature?

[Gray Watson]

In thinking about foreign objects some more and the associated memory issues, I'm thinking about removing the support for the foreignAutoRefresh feature.

Right now we have to process a type when we have a foreign class when really all we need is the idField of that type. But the auto-refresh feature needs the whole type...

Anyone want to push back? Now's your chance.
gray

[Adam Brown]

If the performance gain / code simplification is good enough I'd say go for it.

I've personally been debating it's use in my project because, while certain Foreign fields are small enough that it makes sense, mixing auto/manual refresh foreign fields makes the DAO usage inconsistent throughout my code.

[jc]

I'm not against it. I prefer manual control over when foreign objects
get retrieved so don't use this feature.

[glenviewjeff]

I didn't want to chime in before I've actually used it. Now that I
have, at this point I would be disappointed if it were to go. In
fact, I was going to make a related feature request to allow a
companion "foreignAutoCreate" as follows:

If I were to annotate a field with foreignAutoCreate, it would
automatically create the field in the database. For now, I have to
write a lot of code to create foreign classes (create a Dao interface,
implementation, override the create method with code that creates the
foreign class.)

It would be really nice if this were built in. If these features are
bringing OrmLite closer to "heavier weight" Orms and causing some
additional overhead even for people not using these features, I
understand if you want to ignore/abandon them.

Thanks,
Jeff

[Gray Watson]

On Apr 21, 2011, at 3:42 PM, glenviewjeff wrote:

> I didn't want to chime in before I've actually used it. Now that I
> have, at this point I would be disappointed if it were to go. In
> fact, I was going to make a related feature request to allow a
> companion "foreignAutoCreate" as follows:

So how would this work? Would ORMLite get the id field value from the object and if it was the default value (0, null, etc.) it would do the create otherwise it would not?

gray

[glenviewjeff]

I'm using it in conjunction with generatedId = true, so I hadn't
thought about it. I would assume it would work the same way create
works on an individual persisted class. If I try to run the
Dao.create() method on a class with id=true, and the ID isn't
initialized, what happens? I assume an exception is thrown?

To clarify, the case where this is useful is when you have a one-to-
one mapping between the class class and foreign field class, such that
instantiating/persisting one always results in instantiating/
persisting the other.

[jc]

On Apr 21, 9:29 pm, glenviewjeff <j...@theaxelrods.com> wrote:
>
> To clarify, the case where this is useful is when you have a one-to-
> one mapping between the class class and foreign field class, such that
> instantiating/persisting one always results in instantiating/
> persisting the other.
>

Based on that description, it sounds like you are asking for a
"cascade insert"? Is this really useful since it would result in
always inserting an empty record into the foreign table with only the
parent ID populate.

From a pure database perspective, this would not be very efficient and
would result in a lot of extra/useless data which is why "cascade
insert" isn't directly supported by databases without custom triggers.

[glenviewjeff]

Why would an empty record be created if the object is already
instantiated and initialized before calling create()? In my current
design, here's a simplified flow:

public class ItemDaoJdbc extends BaseDaoImpl<Item, Integer> implements
ItemDao {
...
@Override
public int create(Item anItem) throws SQLException {
DaoManager.createDao(connectionSource,
Aggregate.class).create(anItem.getAggregate());
return super.create(anItem);
}
}

and the client uses the create() as follows:

Item anItem = new Item(a,b,c,...); // Item()'s constructor
instantiates and initializes its aggregate class
itemDao.create(anItem); // Calls create method shown above.

As far as how to implement this goes, after doing a bit more research
into this, I see that Hibernate uses these kinds of annotations. I
don't think it makes sense to reinvent the wheel, so sharing the same
notation would be great. OrmLite is my first Orm experience, so I'm
not sure exactly how these are used in Hibernate, but here's the list
of cascade cascade attributes.

■ cascade="none", the default, tells NHibernate to ignore the
association.
■ cascade="save-update" tells NHibernate to navigate the association
when the
transaction is committed and when an object is passed to Save() or
Update()
and save newly instantiated transient instances and persist changes to
detached
instances.
■ cascade="delete" tells NHibernate to navigate the association and
delete persistent
instances when an object is passed to Delete().
■ cascade="all" means to cascade both save-update and delete, as well
as calls to
Evict and Lock.
■ cascade="all-delete-orphan" means the same as cascade="all" but, in
addition,
NHibernate deletes any persistent entity instance that has been
removed
(dereferenced) from the association (for example, from a collection).
■ cascade="delete-orphan" has NHibernate delete any persistent entity
instance
that has been removed (dereferenced) from the association (for
example, from
a collection).

I hadn't thought about cascading deletes and updates too, which will
also be useful. It would be nice if these were supported on both
collections and individual fields.

Thanks,
Jeff

[jc]

thanks for the details, I think I misunderstood what you were asking
for and this makes a lot more sense. If foreign auto-refresh remains
as a feature, I can see how that would be useful. Maybe Gray can use
javax.persistence.CascadeType in the definition to give some better
control over how the foreign object refresh to incorporate what you
want?

[glenviewjeff]

Yes, that would be great and most appreciated! I mentioned to Gray
that I plan to eventually migrate my design to a persistence DSL (and
share it) using Jetbrains MPS, so this isn't essential for me.
However, the more OrmLite can support the less code generator work I
will have, and I think OrmLite will reach a much wider audience than
hoping people to adopt a new IDE and development methodology (MPS.)

Jeff