Elias Torres wrote:
Or you could defer this type of work for later and code it directly; I
agree with Allen that you'ld probably not be setting a precedent by
doing so.
I'd like more specific instructions on what do you mean by coding it
directly please.
Well, you could override the copyTo() and copyFrom() methods in the
WeblogEntryFormEx class and only copy the over the data that needs to be
copied. e.g. removing the calls to getTags() and setTags()
automatically embedded in those methods when they are auto-generated.
Thanks for the suggestion but I'm not sure it solves the problem. We
already override copyTo and copyFrom which is where we do extra logic
for non-simple types. Therefore moving them from the auto-generated code
to the overridden code doesn't solve my problem because I can't
distinguish between copyTo/copyFrom in the action lifecycle and in the
dummy method that creates a transient entry. I'm sure I can find a
workaround (like adding getRemovedTags()/getAddedTags()) but I'm hoping
for a suggestion that has the least chance of introducing bugs in the
codebase or elegant.
In general I'm getting that putting code that modifies the db inside the
POJO might be just the wrong approach since Hibernate does support
transient and detached objects. Therefore we should try to do things in
the WeblogManager.save(). Any objections of going that route?
Maybe I don't fully understand the problem because I am not working on
the code, but somehow it feels like we are making this too complicated.
I think you should be focusing on the way the formbean/action process
works, not on the pojo. Why don't you just use the formbean to extract
the list of tags which were entered by the user, and then in the struts
action you can figure out which tags are being added/removed and call
the appropriate manager methods to update the aggregate data for those tags.
I know that it seems nice if a call to entry.addTag() automatically
updates the aggregate data for a tag, but maybe that's not really ideal.
As Anil suggested, that creates a dependency between a tag and it's
aggregate data which we don't necessarily want, so instead of putting
the logic in the pojo method just put it wherever calls that method,
namely the struts action. So whatever is calling entry.addTag() can
also call weblogMgr.incrementTagAgg().
-- Allen
-Elias
-- Allen
-Elias
--a.
----- Original Message ----- From: "Elias Torres" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, October 02, 2006 2:42 PM
Subject: Re: How to maintain tag aggregate table?
I started trying option #1 and added a method updateTagCount(String
name, WebsiteData website, int amount) to WeblogManager with respective
calls in WeblogEntryData.addTag() and WeblogEntryData.removeTag() but
ran into a wall.
The problem is in the .copyTo, .copyFrom methods which are doing copies
on detached objects (like in the WeblogEntryPageModel) so I would
end up
double counting some tags.
/** returns a dummied-up weblog entry object */
public WeblogEntryData getWeblogEntry() throws RollerException
{
if (weblogEntry == null)
{
weblogEntry = new WeblogEntryData();
weblogEntry.setWebsite(getWebsite());
form.copyTo(weblogEntry,
getRequest().getLocale(),
getRequest().getParameterMap());
weblogEntry.setWebsite(weblogEntry.getWebsite());
}
return weblogEntry;
}
NOTE: I don't think we need that last call to setWebsite:
weblogEntry.setWebsite(weblogEntry.getWebsite());
Now I understand the comment in HibernatePersistenceStragegy on the
subject:
/*
technically we shouldn't have any reason to support the saving
of detached objects, so at some point we should re-evaluate this.
objects should be re-attached before being saved again. it would
be more appropriate to reject these kinds of saves because they are
not really safe.
NOTE: this may be coming from the way we use formbeans on the UI.
we very commonly repopulate all data in a pojo (including id) from
form data rather than properly loading the object from a Session
then modifying its properties.
*/
Any suggestions on how to differentiate between a copyTo/copyFrom to a
detached object so I don't recount? or should I go with the external
approach of keeping track of tags added/tags removed. It seems to me
that either way we have an issue with these detached objects.
-Elias
Allen Gilliland wrote:
Elias Torres wrote:
Everyone,
I'm changing my code that updated the aggregated tags table from
using a
task to using code during the life of the request i.e. as we save
each
entry.
My question is as follows:
In WeblogEntryData we have addTag() and removeTag() meaning I have
two
options:
- I can call WeblogManager.updateTagStat(Tag) on each
addTag/removeTag()
- I can perform the tag stats updates inside
WeblogManager.save(Entry)
I don't like the first as much but the second one requires me I keep
track of added/removed tags so I can access that information at save
time. ie. entry.getAddedTags(), entry.getRemovedTags().
I would just go for the first option. It's nice if we don't have to
refer to managers from the pojos, but to not do that would make things
harder on ourselves, so just do it. I am pretty sure we are already
doing that anyways.
-- Allen
What do you think?
-Elias
