You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Allen Gilliland <Al...@Sun.COM> on 2005/11/02 01:35:29 UTC
help plz! solving the roller 2.0 intermittent "null" bug
guys, i'm hoping we can use a bit of our collective brain power to try
and figure out the final hows and whys of what's causing this bug.
For anyone who hasn't noticed this bug yet, the basics are that in a
seemingly random pattern, a select number of weblog entries will render
improperly. The result will be a "null" value for the entry body if the
affected entry is the most recent entry for the weblog, otherwise the
result will show a duplicate entry body (i.e. the same entry body shown
for 2 consecutive entries).
I've done a lot of debugging of this problem over the past couple days
and I've traced the problem as such. Inside the #showEntryText($entry)
macro, the line "#set( $entryText = $pageHelper.renderPlugins( $entry )
)" is mysteriously returning null for some group of (seemingly random)
weblog entries. I have not been able to reproduce this on any weblog
with consistency, but the problem always seems to be occurring on one or
two weblogs at a time.
After tracing through the renderPlugins() method I narrowed the problem
down to the line ...
WeblogEntryData copy = new WeblogEntryData(entry.getPojo());
... where the problem is occuring because the copy entry has all null
values. By all null values I mean that calling copy.getId() or
copy.getText() will return you a null. Additional debugging shows that
the value of entry.getPojo() does not have any missing data. Note that
this copy with null values only happens on that limited number of
entries that exhibit the problem. All other entries (the majority) go
through this same process and end up with a perfectly valid copy filled
with all the right values.
I then added debugging messages inside the WeblogEntryData(otherEntry)
constructor and WeblogEntryData.setData(otherEntry) methods and found
that for some reason on the bug affected entries, the values of
otherEntry.* (when accessed directly) will always end up being null, but
the values of otherEntry.getXXX() comes out with the correct data at all
times.
This means that when an entry is being affected by this bug, for some
reason you cannot access the attributes of the entry directly because
they end up null, however if you access the attributes of the entry
through the getter methods the data comes out fine.
Now, I could simply convert the body of the setData() method to use the
getter methods instead of accessing the properties directly, but I would
like to fully understand the problem first. What bothers me is that ...
- almost none of this code has changed between roller 1.3 and roller
2.0. a couple additional lines were added to the
WeblogEntryData.setData() method which were additions for 2.0, but
nothing fundamental has changed.
- all rendered entries go through the exact same process, so why are
this very select few entries on seemingly random weblogs exhibiting this
problem and ending up with null copies?
- often times this problem will be seen on the homepage for a weblog,
but when viewing the permalink of the affected entry or the weblog
preview page the problem does not exist. why?
- the problem also seems to jump around, affecting a given weblog for a
couple days (maybe until the user posts a new entry?) and then it will
stop happening.
- also strange is that you can typically fix the problem (at least in
the short term) by simply triggering a re-rendering of the page. i.e.
by saving your website settings again. you don't actually have to
change anything, simply make an update that would cause a re-rendering
and the problem will often go away. why?
Right now I am still uncertain of the actual cause of the problem. I've
narrowed down exactly where the problem is happening, but I don't know
the conditions which cause the problem. I've compared the roller 1.3
and 2.0 code base and the only difference which seems like it could
possibly be relevant is that the WeblogEntryData object now extends a
class called WebsiteObject rather than the traditional PersistentObject
class. I don't have any idea why that would cause this problem though.
So, i'm sorry that was so long winded, but my hope is that someone else
on this list may be able to offer me a clue as to what is causing this
problem so we can figure out the best way to fix it.
-- Allen
Re: About to commit fix (was Re: help plz! solving the roller 2.0
intermittent "null" bug)
Posted by Allen Gilliland <Al...@Sun.COM>.
On Thu, 2005-11-03 at 04:38, Dave Johnson wrote:
> On Nov 3, 2005, at 4:43 AM, Anil Gangolli wrote:
> > No real objection here, but a comment.
> >
> > Even for the case of lazy loading, the use of getters for all internal
> > acess may be overkill. A given object should get instantiated before
> > entry to any of its methods, so code within that method should be able
> > to directly use "proper" (non-relational) members. I think basically
> > what's biting us is the reaching in from one instance to another
> > instance's members (which we do in the setData() / "copy constructor"
> > methods and typically also in equals() .).
>
> We ran into some problems yesterday with the all getters & setters
> approach and we're only going to handle the setData() and copy
> constructor cases as you suggest.
I think it's also important to make sure all the attributes are changed to "private" level access. I am going to make that change in all the updates I will be committing.
-- Allen
>
>
> > I admit that being pedantic about member access eliminates any
> > reliance on specific Hibernate semantics around instantiation, (which
> > I've had a hard time finding described very completely). On the other
> > hand, if we had an adequate understanding of Hibernate's precise
> > instantiation semantics, we may feel confident in maintaining what
> > seems to me to be simpler code (even with lazy loading enabled).
>
> Agreed.
>
> - Dave
>
>
>
>
> >
> > --a.
> >
> > Dave Johnson wrote:
> >
> >> Allen and I are getting ready to commit a fix for ROL-865
> >> http://opensource2.atlassian.com/projects/roller/browse/ROL-865
> >>
> >> This is a fairly big fix, so extra warning is needed. There are two
> >> parts to the fix:
> >>
> >> 1) Apply "encapsulate members" refactoring to all POJOs so that all
> >> use getters and setters to access members, even internally. This
> >> should ensure that Hibernate lazy-loading will work, when it is in
> >> effect.
> >>
> >> 2) Upgrade to XDoclet 1.2.3 and add @hibernate.class lazy="false" to
> >> all POJOs. This will revert our use of lazy-loading back to the way
> >> it was in Roller 1.x, that is lazy-loading is off by default and
> >> turned on explicitly for (most) collections.
> >>
> >> - Dave
> >>
> >>
> >> On Nov 2, 2005, at 1:34 PM, Dave Johnson wrote:
> >>
> >>> I'm going to go ahead and commit my changes to the POJOs. I added
> >>> lazy="false" to each class, but that will have no effect until I
> >>> commit XDoclet 1.2.3.
> >>>
> >>> I'm holding off on committing XDoclet 1.2.3 in case somebody has a
> >>> last minute objection.
> >>>
> >>> Any objections?
> >>>
> >>> - Dave
> >>>
> >>>
> >>> On Nov 2, 2005, at 12:41 PM, Dave Johnson wrote:
> >>>
> >>>>
> >>>> On Nov 2, 2005, at 12:25 PM, Allen Gilliland wrote:
> >>>>
> >>>>> So it sounds like there are a couple options ...
> >>>>> 1. alter our hibernate mappings to for lazy="false" by default.
> >>>>> this would require upgrading our xdoclet version.
> >>>>> 2. alter our pojos to force the use of getters/setters and prevent
> >>>>> the use of direct accessors.
> >>>>
> >>>>
> >>>> Assuming we've correctly identified the problem, #2 alone should
> >>>> solve it.
> >>>>
> >>>>
> >>>>> personally, i think we should do both, but i would be more adamant
> >>>>> about doing #2. the standard pojo/bean pattern recommends that
> >>>>> attributes be private and only accessed through getters and
> >>>>> setters and i believe we should adhere to that. it seems pretty
> >>>>> lame that hibernate couldn't deal with direct access, but oh well.
> >>>>> with a bit of IDE wizardry it shouldn't be too hard to make this
> >>>>> happen.
> >>>>>
> >>>>> of course it also makes sense that we probably don't need to use
> >>>>> lazy loading on *all* pojo properties, so defaulting to
> >>>>> lazy="false" would be a good thing too. i don't know all the
> >>>>> details about why that was changed in hibernate 3, maybe there is
> >>>>> a good reason to use lazy loading all the time? maybe this would
> >>>>> account for the performance improvements you noted on your site
> >>>>> Dave?
> >>>>
> >>>>
> >>>> That's possible, I guess, but I really don't know the answer.
> >>>>
> >>>>
> >>>>> what does everyone else prefer to do?
> >>>>
> >>>>
> >>>> I'd prefer to do both #1 and #2 right now, but could be talked into
> >>>> saving #1 for later.
> >>>>
> >>>> - Dave
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> -- Allen
> >>>>>
> >>>>>
> >>>>> On Wed, 2005-11-02 at 06:17, Dave Johnson wrote:
> >>>>>
> >>>>>> On Nov 2, 2005, at 7:44 AM, Dave Johnson wrote:
> >>>>>>
> >>>>>>>> Anil wrote:
> >>>>>>>> Changing the loading behavior in the mappings to be non-lazy one
> >>>>>>>> should be able to avoid this behavior. If we have a lot of code
> >>>>>>>> dealing with pojo members directly, we may want to do this. I
> >>>>>>>> believe the laziness defaults changed between 2.x and 3.x.
> >>>>>>>
> >>>>>>>
> >>>>>>> The more involved fix is to upgrade to the latest XDoclet (which
> >>>>>>> may
> >>>>>>> require building it from CVS to get around that bug that bit
> >>>>>>> me), set
> >>>>>>> lazy="false" at the class level and set lazy="true" for the
> >>>>>>> individual
> >>>>>>> collections that we want to be lazy-loaded (and I think we're
> >>>>>>> already
> >>>>>>> doing that). We're using XDoclet 1.2b4 and the latest XDoclet is
> >>>>>>> 1.2.
> >>>>>>
> >>>>>>
> >>>>>> I've implemented that more involved fix in my workspace. I
> >>>>>> upgraded to
> >>>>>> XDoclet 1.2.3, found a reasonable work-around for that bug I
> >>>>>> mentioned
> >>>>>> and set lazy="false" at the @hibernate.class level for all 28 of
> >>>>>> our
> >>>>>> POJOS. Roller appears to be working fine in my workspace.
> >>>>>>
> >>>>>> There are three reasons why we might want to commit this for 2.0:
> >>>>>> 1) it solves the intermittent null problem (we need to verify
> >>>>>> this)
> >>>>>> 2) it's better to use an official release of XDoclet rather than
> >>>>>> custom
> >>>>>> 1.2b4 build
> >>>>>> 3) it's better to stick with lazy="false" since that's what we
> >>>>>> were
> >>>>>> doing before 2.0
> >>>>>>
> >>>>>> Since I can't duplicate the intermittent null problem, Allen
> >>>>>> needs to
> >>>>>> verify that #1 is a true statement.
> >>>>>>
> >>>>>> - Dave
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >>
> >
>
Re: About to commit fix (was Re: help plz! solving the roller 2.0 intermittent "null" bug)
Posted by Dave Johnson <da...@rollerweblogger.org>.
On Nov 3, 2005, at 10:40 AM, Anil Gangolli wrote:
> A bit more on equals().
>
> (1) We have a default reflective implementation of equals in
> PersistentObject (I think), and I believe it is uses field-level
> reflection, not "bean-style" property getter introspection/reflection.
> This may be dangerous..
Since we've now turned off lazy-loading at the class level, I hope
we're back to the same danger-level we had in 1.x.
> (2) When we do override equals(Object other), we have a tendency to
> reach into other.field for comparisons. I don't know if Hibernate
> proxies are "smart" enough to instantiate both x and y when
> x.equals(y) is invoked, so we should also use getters there to be
> safe.
>
> (3) Hibernate recommends a weak "semi-unique" equals based on business
> keys only, for a reason I haven't fully grasped yet. We tend to
> implement traditional strong equals. This might be something to
> reexamine.
Yes, I agree. The equals() methods in most POJOs were originally
generated by the XDoclet EJB Data Transfer Object generator and they
were simply left in-place when we stopped generating our POJOs.
- Dave
Re: About to commit fix (was Re: help plz! solving the roller 2.0
intermittent "null" bug)
Posted by Anil Gangolli <an...@busybuddha.org>.
A bit more on equals().
(1) We have a default reflective implementation of equals in
PersistentObject (I think), and I believe it is uses field-level
reflection, not "bean-style" property getter introspection/reflection.
This may be dangerous..
(2) When we do override equals(Object other), we have a tendency to
reach into other.field for comparisons. I don't know if Hibernate
proxies are "smart" enough to instantiate both x and y when x.equals(y)
is invoked, so we should also use getters there to be safe.
(3) Hibernate recommends a weak "semi-unique" equals based on business
keys only, for a reason I haven't fully grasped yet. We tend to
implement traditional strong equals. This might be something to reexamine.
--a.
Dave Johnson wrote:
>
> On Nov 3, 2005, at 4:43 AM, Anil Gangolli wrote:
>
>> No real objection here, but a comment.
>>
>> Even for the case of lazy loading, the use of getters for all
>> internal acess may be overkill. A given object should get
>> instantiated before entry to any of its methods, so code within that
>> method should be able to directly use "proper" (non-relational)
>> members. I think basically what's biting us is the reaching in from
>> one instance to another instance's members (which we do in the
>> setData() / "copy constructor" methods and typically also in equals()
>> .).
>
>
> We ran into some problems yesterday with the all getters & setters
> approach and we're only going to handle the setData() and copy
> constructor cases as you suggest.
>
>
>> I admit that being pedantic about member access eliminates any
>> reliance on specific Hibernate semantics around instantiation, (which
>> I've had a hard time finding described very completely). On the
>> other hand, if we had an adequate understanding of Hibernate's
>> precise instantiation semantics, we may feel confident in maintaining
>> what seems to me to be simpler code (even with lazy loading enabled).
>
>
> Agreed.
>
> - Dave
>
>
>
>
>>
>> --a.
>>
>> Dave Johnson wrote:
>>
>>> Allen and I are getting ready to commit a fix for ROL-865
>>> http://opensource2.atlassian.com/projects/roller/browse/ROL-865
>>>
>>> This is a fairly big fix, so extra warning is needed. There are two
>>> parts to the fix:
>>>
>>> 1) Apply "encapsulate members" refactoring to all POJOs so that all
>>> use getters and setters to access members, even internally. This
>>> should ensure that Hibernate lazy-loading will work, when it is in
>>> effect.
>>>
>>> 2) Upgrade to XDoclet 1.2.3 and add @hibernate.class lazy="false" to
>>> all POJOs. This will revert our use of lazy-loading back to the way
>>> it was in Roller 1.x, that is lazy-loading is off by default and
>>> turned on explicitly for (most) collections.
>>>
>>> - Dave
>>>
>>>
>>> On Nov 2, 2005, at 1:34 PM, Dave Johnson wrote:
>>>
>>>> I'm going to go ahead and commit my changes to the POJOs. I added
>>>> lazy="false" to each class, but that will have no effect until I
>>>> commit XDoclet 1.2.3.
>>>>
>>>> I'm holding off on committing XDoclet 1.2.3 in case somebody has a
>>>> last minute objection.
>>>>
>>>> Any objections?
>>>>
>>>> - Dave
>>>>
>>>>
>>>> On Nov 2, 2005, at 12:41 PM, Dave Johnson wrote:
>>>>
>>>>>
>>>>> On Nov 2, 2005, at 12:25 PM, Allen Gilliland wrote:
>>>>>
>>>>>> So it sounds like there are a couple options ...
>>>>>> 1. alter our hibernate mappings to for lazy="false" by default.
>>>>>> this would require upgrading our xdoclet version.
>>>>>> 2. alter our pojos to force the use of getters/setters and
>>>>>> prevent the use of direct accessors.
>>>>>
>>>>>
>>>>>
>>>>> Assuming we've correctly identified the problem, #2 alone should
>>>>> solve it.
>>>>>
>>>>>
>>>>>> personally, i think we should do both, but i would be more
>>>>>> adamant about doing #2. the standard pojo/bean pattern
>>>>>> recommends that attributes be private and only accessed through
>>>>>> getters and setters and i believe we should adhere to that. it
>>>>>> seems pretty lame that hibernate couldn't deal with direct
>>>>>> access, but oh well. with a bit of IDE wizardry it shouldn't be
>>>>>> too hard to make this happen.
>>>>>>
>>>>>> of course it also makes sense that we probably don't need to use
>>>>>> lazy loading on *all* pojo properties, so defaulting to
>>>>>> lazy="false" would be a good thing too. i don't know all the
>>>>>> details about why that was changed in hibernate 3, maybe there is
>>>>>> a good reason to use lazy loading all the time? maybe this would
>>>>>> account for the performance improvements you noted on your site
>>>>>> Dave?
>>>>>
>>>>>
>>>>>
>>>>> That's possible, I guess, but I really don't know the answer.
>>>>>
>>>>>
>>>>>> what does everyone else prefer to do?
>>>>>
>>>>>
>>>>>
>>>>> I'd prefer to do both #1 and #2 right now, but could be talked
>>>>> into saving #1 for later.
>>>>>
>>>>> - Dave
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> -- Allen
>>>>>>
>>>>>>
>>>>>> On Wed, 2005-11-02 at 06:17, Dave Johnson wrote:
>>>>>>
>>>>>>> On Nov 2, 2005, at 7:44 AM, Dave Johnson wrote:
>>>>>>>
>>>>>>>>> Anil wrote:
>>>>>>>>> Changing the loading behavior in the mappings to be non-lazy one
>>>>>>>>> should be able to avoid this behavior. If we have a lot of code
>>>>>>>>> dealing with pojo members directly, we may want to do this. I
>>>>>>>>> believe the laziness defaults changed between 2.x and 3.x.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The more involved fix is to upgrade to the latest XDoclet
>>>>>>>> (which may
>>>>>>>> require building it from CVS to get around that bug that bit
>>>>>>>> me), set
>>>>>>>> lazy="false" at the class level and set lazy="true" for the
>>>>>>>> individual
>>>>>>>> collections that we want to be lazy-loaded (and I think we're
>>>>>>>> already
>>>>>>>> doing that). We're using XDoclet 1.2b4 and the latest XDoclet
>>>>>>>> is 1.2.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I've implemented that more involved fix in my workspace. I
>>>>>>> upgraded to
>>>>>>> XDoclet 1.2.3, found a reasonable work-around for that bug I
>>>>>>> mentioned
>>>>>>> and set lazy="false" at the @hibernate.class level for all 28 of
>>>>>>> our
>>>>>>> POJOS. Roller appears to be working fine in my workspace.
>>>>>>>
>>>>>>> There are three reasons why we might want to commit this for 2.0:
>>>>>>> 1) it solves the intermittent null problem (we need to verify this)
>>>>>>> 2) it's better to use an official release of XDoclet rather than
>>>>>>> custom
>>>>>>> 1.2b4 build
>>>>>>> 3) it's better to stick with lazy="false" since that's what we were
>>>>>>> doing before 2.0
>>>>>>>
>>>>>>> Since I can't duplicate the intermittent null problem, Allen
>>>>>>> needs to
>>>>>>> verify that #1 is a true statement.
>>>>>>>
>>>>>>> - Dave
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
Re: About to commit fix (was Re: help plz! solving the roller 2.0 intermittent "null" bug)
Posted by Dave Johnson <da...@rollerweblogger.org>.
On Nov 3, 2005, at 4:43 AM, Anil Gangolli wrote:
> No real objection here, but a comment.
>
> Even for the case of lazy loading, the use of getters for all internal
> acess may be overkill. A given object should get instantiated before
> entry to any of its methods, so code within that method should be able
> to directly use "proper" (non-relational) members. I think basically
> what's biting us is the reaching in from one instance to another
> instance's members (which we do in the setData() / "copy constructor"
> methods and typically also in equals() .).
We ran into some problems yesterday with the all getters & setters
approach and we're only going to handle the setData() and copy
constructor cases as you suggest.
> I admit that being pedantic about member access eliminates any
> reliance on specific Hibernate semantics around instantiation, (which
> I've had a hard time finding described very completely). On the other
> hand, if we had an adequate understanding of Hibernate's precise
> instantiation semantics, we may feel confident in maintaining what
> seems to me to be simpler code (even with lazy loading enabled).
Agreed.
- Dave
>
> --a.
>
> Dave Johnson wrote:
>
>> Allen and I are getting ready to commit a fix for ROL-865
>> http://opensource2.atlassian.com/projects/roller/browse/ROL-865
>>
>> This is a fairly big fix, so extra warning is needed. There are two
>> parts to the fix:
>>
>> 1) Apply "encapsulate members" refactoring to all POJOs so that all
>> use getters and setters to access members, even internally. This
>> should ensure that Hibernate lazy-loading will work, when it is in
>> effect.
>>
>> 2) Upgrade to XDoclet 1.2.3 and add @hibernate.class lazy="false" to
>> all POJOs. This will revert our use of lazy-loading back to the way
>> it was in Roller 1.x, that is lazy-loading is off by default and
>> turned on explicitly for (most) collections.
>>
>> - Dave
>>
>>
>> On Nov 2, 2005, at 1:34 PM, Dave Johnson wrote:
>>
>>> I'm going to go ahead and commit my changes to the POJOs. I added
>>> lazy="false" to each class, but that will have no effect until I
>>> commit XDoclet 1.2.3.
>>>
>>> I'm holding off on committing XDoclet 1.2.3 in case somebody has a
>>> last minute objection.
>>>
>>> Any objections?
>>>
>>> - Dave
>>>
>>>
>>> On Nov 2, 2005, at 12:41 PM, Dave Johnson wrote:
>>>
>>>>
>>>> On Nov 2, 2005, at 12:25 PM, Allen Gilliland wrote:
>>>>
>>>>> So it sounds like there are a couple options ...
>>>>> 1. alter our hibernate mappings to for lazy="false" by default.
>>>>> this would require upgrading our xdoclet version.
>>>>> 2. alter our pojos to force the use of getters/setters and prevent
>>>>> the use of direct accessors.
>>>>
>>>>
>>>> Assuming we've correctly identified the problem, #2 alone should
>>>> solve it.
>>>>
>>>>
>>>>> personally, i think we should do both, but i would be more adamant
>>>>> about doing #2. the standard pojo/bean pattern recommends that
>>>>> attributes be private and only accessed through getters and
>>>>> setters and i believe we should adhere to that. it seems pretty
>>>>> lame that hibernate couldn't deal with direct access, but oh well.
>>>>> with a bit of IDE wizardry it shouldn't be too hard to make this
>>>>> happen.
>>>>>
>>>>> of course it also makes sense that we probably don't need to use
>>>>> lazy loading on *all* pojo properties, so defaulting to
>>>>> lazy="false" would be a good thing too. i don't know all the
>>>>> details about why that was changed in hibernate 3, maybe there is
>>>>> a good reason to use lazy loading all the time? maybe this would
>>>>> account for the performance improvements you noted on your site
>>>>> Dave?
>>>>
>>>>
>>>> That's possible, I guess, but I really don't know the answer.
>>>>
>>>>
>>>>> what does everyone else prefer to do?
>>>>
>>>>
>>>> I'd prefer to do both #1 and #2 right now, but could be talked into
>>>> saving #1 for later.
>>>>
>>>> - Dave
>>>>
>>>>
>>>>
>>>>>
>>>>> -- Allen
>>>>>
>>>>>
>>>>> On Wed, 2005-11-02 at 06:17, Dave Johnson wrote:
>>>>>
>>>>>> On Nov 2, 2005, at 7:44 AM, Dave Johnson wrote:
>>>>>>
>>>>>>>> Anil wrote:
>>>>>>>> Changing the loading behavior in the mappings to be non-lazy one
>>>>>>>> should be able to avoid this behavior. If we have a lot of code
>>>>>>>> dealing with pojo members directly, we may want to do this. I
>>>>>>>> believe the laziness defaults changed between 2.x and 3.x.
>>>>>>>
>>>>>>>
>>>>>>> The more involved fix is to upgrade to the latest XDoclet (which
>>>>>>> may
>>>>>>> require building it from CVS to get around that bug that bit
>>>>>>> me), set
>>>>>>> lazy="false" at the class level and set lazy="true" for the
>>>>>>> individual
>>>>>>> collections that we want to be lazy-loaded (and I think we're
>>>>>>> already
>>>>>>> doing that). We're using XDoclet 1.2b4 and the latest XDoclet is
>>>>>>> 1.2.
>>>>>>
>>>>>>
>>>>>> I've implemented that more involved fix in my workspace. I
>>>>>> upgraded to
>>>>>> XDoclet 1.2.3, found a reasonable work-around for that bug I
>>>>>> mentioned
>>>>>> and set lazy="false" at the @hibernate.class level for all 28 of
>>>>>> our
>>>>>> POJOS. Roller appears to be working fine in my workspace.
>>>>>>
>>>>>> There are three reasons why we might want to commit this for 2.0:
>>>>>> 1) it solves the intermittent null problem (we need to verify
>>>>>> this)
>>>>>> 2) it's better to use an official release of XDoclet rather than
>>>>>> custom
>>>>>> 1.2b4 build
>>>>>> 3) it's better to stick with lazy="false" since that's what we
>>>>>> were
>>>>>> doing before 2.0
>>>>>>
>>>>>> Since I can't duplicate the intermittent null problem, Allen
>>>>>> needs to
>>>>>> verify that #1 is a true statement.
>>>>>>
>>>>>> - Dave
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>
Re: About to commit fix (was Re: help plz! solving the roller 2.0
intermittent "null" bug)
Posted by Anil Gangolli <an...@busybuddha.org>.
No real objection here, but a comment.
Even for the case of lazy loading, the use of getters for all internal
acess may be overkill. A given object should get instantiated before
entry to any of its methods, so code within that method should be able
to directly use "proper" (non-relational) members. I think basically
what's biting us is the reaching in from one instance to another
instance's members (which we do in the setData() / "copy constructor"
methods and typically also in equals() .).
I admit that being pedantic about member access eliminates any reliance
on specific Hibernate semantics around instantiation, (which I've had a
hard time finding described very completely). On the other hand, if we
had an adequate understanding of Hibernate's precise instantiation
semantics, we may feel confident in maintaining what seems to me to be
simpler code (even with lazy loading enabled).
--a.
Dave Johnson wrote:
> Allen and I are getting ready to commit a fix for ROL-865
> http://opensource2.atlassian.com/projects/roller/browse/ROL-865
>
> This is a fairly big fix, so extra warning is needed. There are two
> parts to the fix:
>
> 1) Apply "encapsulate members" refactoring to all POJOs so that all
> use getters and setters to access members, even internally. This
> should ensure that Hibernate lazy-loading will work, when it is in
> effect.
>
> 2) Upgrade to XDoclet 1.2.3 and add @hibernate.class lazy="false" to
> all POJOs. This will revert our use of lazy-loading back to the way it
> was in Roller 1.x, that is lazy-loading is off by default and turned
> on explicitly for (most) collections.
>
> - Dave
>
>
> On Nov 2, 2005, at 1:34 PM, Dave Johnson wrote:
>
>> I'm going to go ahead and commit my changes to the POJOs. I added
>> lazy="false" to each class, but that will have no effect until I
>> commit XDoclet 1.2.3.
>>
>> I'm holding off on committing XDoclet 1.2.3 in case somebody has a
>> last minute objection.
>>
>> Any objections?
>>
>> - Dave
>>
>>
>> On Nov 2, 2005, at 12:41 PM, Dave Johnson wrote:
>>
>>>
>>> On Nov 2, 2005, at 12:25 PM, Allen Gilliland wrote:
>>>
>>>> So it sounds like there are a couple options ...
>>>> 1. alter our hibernate mappings to for lazy="false" by default.
>>>> this would require upgrading our xdoclet version.
>>>> 2. alter our pojos to force the use of getters/setters and prevent
>>>> the use of direct accessors.
>>>
>>>
>>> Assuming we've correctly identified the problem, #2 alone should
>>> solve it.
>>>
>>>
>>>> personally, i think we should do both, but i would be more adamant
>>>> about doing #2. the standard pojo/bean pattern recommends that
>>>> attributes be private and only accessed through getters and setters
>>>> and i believe we should adhere to that. it seems pretty lame that
>>>> hibernate couldn't deal with direct access, but oh well. with a
>>>> bit of IDE wizardry it shouldn't be too hard to make this happen.
>>>>
>>>> of course it also makes sense that we probably don't need to use
>>>> lazy loading on *all* pojo properties, so defaulting to
>>>> lazy="false" would be a good thing too. i don't know all the
>>>> details about why that was changed in hibernate 3, maybe there is a
>>>> good reason to use lazy loading all the time? maybe this would
>>>> account for the performance improvements you noted on your site Dave?
>>>
>>>
>>> That's possible, I guess, but I really don't know the answer.
>>>
>>>
>>>> what does everyone else prefer to do?
>>>
>>>
>>> I'd prefer to do both #1 and #2 right now, but could be talked into
>>> saving #1 for later.
>>>
>>> - Dave
>>>
>>>
>>>
>>>>
>>>> -- Allen
>>>>
>>>>
>>>> On Wed, 2005-11-02 at 06:17, Dave Johnson wrote:
>>>>
>>>>> On Nov 2, 2005, at 7:44 AM, Dave Johnson wrote:
>>>>>
>>>>>>> Anil wrote:
>>>>>>> Changing the loading behavior in the mappings to be non-lazy one
>>>>>>> should be able to avoid this behavior. If we have a lot of code
>>>>>>> dealing with pojo members directly, we may want to do this. I
>>>>>>> believe the laziness defaults changed between 2.x and 3.x.
>>>>>>
>>>>>>
>>>>>> The more involved fix is to upgrade to the latest XDoclet (which may
>>>>>> require building it from CVS to get around that bug that bit me),
>>>>>> set
>>>>>> lazy="false" at the class level and set lazy="true" for the
>>>>>> individual
>>>>>> collections that we want to be lazy-loaded (and I think we're
>>>>>> already
>>>>>> doing that). We're using XDoclet 1.2b4 and the latest XDoclet is
>>>>>> 1.2.
>>>>>
>>>>>
>>>>> I've implemented that more involved fix in my workspace. I
>>>>> upgraded to
>>>>> XDoclet 1.2.3, found a reasonable work-around for that bug I
>>>>> mentioned
>>>>> and set lazy="false" at the @hibernate.class level for all 28 of our
>>>>> POJOS. Roller appears to be working fine in my workspace.
>>>>>
>>>>> There are three reasons why we might want to commit this for 2.0:
>>>>> 1) it solves the intermittent null problem (we need to verify this)
>>>>> 2) it's better to use an official release of XDoclet rather than
>>>>> custom
>>>>> 1.2b4 build
>>>>> 3) it's better to stick with lazy="false" since that's what we were
>>>>> doing before 2.0
>>>>>
>>>>> Since I can't duplicate the intermittent null problem, Allen needs to
>>>>> verify that #1 is a true statement.
>>>>>
>>>>> - Dave
>>>>>
>>>>
>>>
>>
>
>
About to commit fix (was Re: help plz! solving the roller 2.0 intermittent "null" bug)
Posted by Dave Johnson <da...@rollerweblogger.org>.
Allen and I are getting ready to commit a fix for ROL-865
http://opensource2.atlassian.com/projects/roller/browse/ROL-865
This is a fairly big fix, so extra warning is needed. There are two
parts to the fix:
1) Apply "encapsulate members" refactoring to all POJOs so that all use
getters and setters to access members, even internally. This should
ensure that Hibernate lazy-loading will work, when it is in effect.
2) Upgrade to XDoclet 1.2.3 and add @hibernate.class lazy="false" to
all POJOs. This will revert our use of lazy-loading back to the way it
was in Roller 1.x, that is lazy-loading is off by default and turned on
explicitly for (most) collections.
- Dave
On Nov 2, 2005, at 1:34 PM, Dave Johnson wrote:
> I'm going to go ahead and commit my changes to the POJOs. I added
> lazy="false" to each class, but that will have no effect until I
> commit XDoclet 1.2.3.
>
> I'm holding off on committing XDoclet 1.2.3 in case somebody has a
> last minute objection.
>
> Any objections?
>
> - Dave
>
>
> On Nov 2, 2005, at 12:41 PM, Dave Johnson wrote:
>
>>
>> On Nov 2, 2005, at 12:25 PM, Allen Gilliland wrote:
>>> So it sounds like there are a couple options ...
>>> 1. alter our hibernate mappings to for lazy="false" by default.
>>> this would require upgrading our xdoclet version.
>>> 2. alter our pojos to force the use of getters/setters and prevent
>>> the use of direct accessors.
>>
>> Assuming we've correctly identified the problem, #2 alone should
>> solve it.
>>
>>
>>> personally, i think we should do both, but i would be more adamant
>>> about doing #2. the standard pojo/bean pattern recommends that
>>> attributes be private and only accessed through getters and setters
>>> and i believe we should adhere to that. it seems pretty lame that
>>> hibernate couldn't deal with direct access, but oh well. with a bit
>>> of IDE wizardry it shouldn't be too hard to make this happen.
>>>
>>> of course it also makes sense that we probably don't need to use
>>> lazy loading on *all* pojo properties, so defaulting to lazy="false"
>>> would be a good thing too. i don't know all the details about why
>>> that was changed in hibernate 3, maybe there is a good reason to use
>>> lazy loading all the time? maybe this would account for the
>>> performance improvements you noted on your site Dave?
>>
>> That's possible, I guess, but I really don't know the answer.
>>
>>
>>> what does everyone else prefer to do?
>>
>> I'd prefer to do both #1 and #2 right now, but could be talked into
>> saving #1 for later.
>>
>> - Dave
>>
>>
>>
>>>
>>> -- Allen
>>>
>>>
>>> On Wed, 2005-11-02 at 06:17, Dave Johnson wrote:
>>>> On Nov 2, 2005, at 7:44 AM, Dave Johnson wrote:
>>>>>> Anil wrote:
>>>>>> Changing the loading behavior in the mappings to be non-lazy one
>>>>>> should be able to avoid this behavior. If we have a lot of code
>>>>>> dealing with pojo members directly, we may want to do this. I
>>>>>> believe the laziness defaults changed between 2.x and 3.x.
>>>>>
>>>>> The more involved fix is to upgrade to the latest XDoclet (which
>>>>> may
>>>>> require building it from CVS to get around that bug that bit me),
>>>>> set
>>>>> lazy="false" at the class level and set lazy="true" for the
>>>>> individual
>>>>> collections that we want to be lazy-loaded (and I think we're
>>>>> already
>>>>> doing that). We're using XDoclet 1.2b4 and the latest XDoclet is
>>>>> 1.2.
>>>>
>>>> I've implemented that more involved fix in my workspace. I upgraded
>>>> to
>>>> XDoclet 1.2.3, found a reasonable work-around for that bug I
>>>> mentioned
>>>> and set lazy="false" at the @hibernate.class level for all 28 of our
>>>> POJOS. Roller appears to be working fine in my workspace.
>>>>
>>>> There are three reasons why we might want to commit this for 2.0:
>>>> 1) it solves the intermittent null problem (we need to verify this)
>>>> 2) it's better to use an official release of XDoclet rather than
>>>> custom
>>>> 1.2b4 build
>>>> 3) it's better to stick with lazy="false" since that's what we were
>>>> doing before 2.0
>>>>
>>>> Since I can't duplicate the intermittent null problem, Allen needs
>>>> to
>>>> verify that #1 is a true statement.
>>>>
>>>> - Dave
>>>>
>>>
>>
>
Objections to XDoclet 1.2.3? (was Re: help plz! solving the roller 2.0 intermittent "null" bug)
Posted by Dave Johnson <da...@rollerweblogger.org>.
I'm going to go ahead and commit my changes to the POJOs. I added
lazy="false" to each class, but that will have no effect until I commit
XDoclet 1.2.3.
I'm holding off on committing XDoclet 1.2.3 in case somebody has a last
minute objection.
Any objections?
- Dave
On Nov 2, 2005, at 12:41 PM, Dave Johnson wrote:
>
> On Nov 2, 2005, at 12:25 PM, Allen Gilliland wrote:
>> So it sounds like there are a couple options ...
>> 1. alter our hibernate mappings to for lazy="false" by default. this
>> would require upgrading our xdoclet version.
>> 2. alter our pojos to force the use of getters/setters and prevent
>> the use of direct accessors.
>
> Assuming we've correctly identified the problem, #2 alone should solve
> it.
>
>
>> personally, i think we should do both, but i would be more adamant
>> about doing #2. the standard pojo/bean pattern recommends that
>> attributes be private and only accessed through getters and setters
>> and i believe we should adhere to that. it seems pretty lame that
>> hibernate couldn't deal with direct access, but oh well. with a bit
>> of IDE wizardry it shouldn't be too hard to make this happen.
>>
>> of course it also makes sense that we probably don't need to use lazy
>> loading on *all* pojo properties, so defaulting to lazy="false" would
>> be a good thing too. i don't know all the details about why that was
>> changed in hibernate 3, maybe there is a good reason to use lazy
>> loading all the time? maybe this would account for the performance
>> improvements you noted on your site Dave?
>
> That's possible, I guess, but I really don't know the answer.
>
>
>> what does everyone else prefer to do?
>
> I'd prefer to do both #1 and #2 right now, but could be talked into
> saving #1 for later.
>
> - Dave
>
>
>
>>
>> -- Allen
>>
>>
>> On Wed, 2005-11-02 at 06:17, Dave Johnson wrote:
>>> On Nov 2, 2005, at 7:44 AM, Dave Johnson wrote:
>>>>> Anil wrote:
>>>>> Changing the loading behavior in the mappings to be non-lazy one
>>>>> should be able to avoid this behavior. If we have a lot of code
>>>>> dealing with pojo members directly, we may want to do this. I
>>>>> believe the laziness defaults changed between 2.x and 3.x.
>>>>
>>>> The more involved fix is to upgrade to the latest XDoclet (which may
>>>> require building it from CVS to get around that bug that bit me),
>>>> set
>>>> lazy="false" at the class level and set lazy="true" for the
>>>> individual
>>>> collections that we want to be lazy-loaded (and I think we're
>>>> already
>>>> doing that). We're using XDoclet 1.2b4 and the latest XDoclet is
>>>> 1.2.
>>>
>>> I've implemented that more involved fix in my workspace. I upgraded
>>> to
>>> XDoclet 1.2.3, found a reasonable work-around for that bug I
>>> mentioned
>>> and set lazy="false" at the @hibernate.class level for all 28 of our
>>> POJOS. Roller appears to be working fine in my workspace.
>>>
>>> There are three reasons why we might want to commit this for 2.0:
>>> 1) it solves the intermittent null problem (we need to verify this)
>>> 2) it's better to use an official release of XDoclet rather than
>>> custom
>>> 1.2b4 build
>>> 3) it's better to stick with lazy="false" since that's what we were
>>> doing before 2.0
>>>
>>> Since I can't duplicate the intermittent null problem, Allen needs to
>>> verify that #1 is a true statement.
>>>
>>> - Dave
>>>
>>
>
Re: Oracle patch fro 2.0
Posted by Allen Gilliland <Al...@Sun.COM>.
i thought we were okay with table names, i thought the problem was index
and foreign key names?
we already have a table name which is longer ...
"roller_user_permissions", which supposedly you've already tested and
okayed for derby/db2?
-- Allen
On Tue, 2005-11-08 at 09:42, Elias Torres wrote:
> There might be a name too long problem, but besides that any more
> meaningful name by Allen, would be ok with me.
>
> Elias
>
> On 11/8/05, Allen Gilliland <Al...@sun.com> wrote:
> > I am okay with this these db changes as well, however I think we should
> > rename the comment table to something a little more appropriate, like
> > "roller_weblogcomments". We may need to setup different syntax to do
> > that for various dbs.
> >
> > Then as Dave said, I don't think we need any of that stuff for the audit
> > log table. That table is new in 2.0, so we just need to alter it's
> > definition in the 2.0 createdb.sql file.
> >
> > -- Allen
> >
> >
> > On Tue, 2005-11-08 at 07:30, Dave Johnson wrote:
> > > This patch database schema changes (shown below), so if we don't get it
> > > into 2.0, it'll have to wait for 3.0.
> > >
> > > alter table comment rename to blogcomment;
> > > alter table roller_audit_log add column comment_text varchar(255);
> > > update roller_audit_log set comment_text = comment;
> > > alter table roller_audit_log modify comment_text varchar(255) not
> > > null;
> > > alter table roller_audit_log drop column comment;
> > >
> > > The rename syntax is in the docs for MySQL and PostgreSQL. The
> > > roller_audit_log table is totally unused at this point, so related
> > > changes are not an issue.
> > >
> > > All in all, the patch looks very safe.
> > >
> > > Can I sneak it in before 2.0 goes final?
> > >
> > > - Dave
> > >
> > >
> > >
> > > On Nov 6, 2005, at 2:55 PM, Max Rudman wrote:
> > >
> > > > Hi Dave,
> > > >
> > > > Sorry for a long delay in getting this to you -- I got busy at the day
> > > > job. At any rate, attached is the patch for Oracle compatibility and
> > > > db_oracle.properties file. Here are the two main changes I had to
> > > > make:
> > > >
> > > > 1) Updated createdb-raw.sql to change 'comment' table to 'blogcomment'
> > > > and 'roller_audit_log.comment' column to 'comment_text' column. The
> > > > reason for these is that 'comment' is a reserved word in Oracle 10g. I
> > > > also updated XDoclet tags in the appropriate POJOs to have the above
> > > > cahnages reflected in Hibernate mapping files.
> > > >
> > > > 2) Added an Oracle "if" clause to the
> > > > HibernateRefererManagerImpl.getDaysPopularWebsites method which runs
> > > > the JDBC-based query.
> > > >
> > > > There are also a few miscellaneous changes to the config files
> > > > (build.xml, hibernate.cfg.xml) for obvious reasons. Please review and
> > > > let me know if you have any questions.
> > > >
> > > > I've tested the parts where I made changes against Oracle 10g Release
> > > > 2 on Windows. We've also had the app based on Roller code running in
> > > > production against Oracle for some time now. However, it only uses a
> > > > subset of Roller functionality so I am not sure about more obscure
> > > > parts of the codebase.
> > > >
> > > > Max
> > > >
> > > > <roller-oracle-patch.txt><db_oracle.properties>
> > >
> >
> >
Re: Oracle patch fro 2.0
Posted by Elias Torres <el...@torrez.us>.
There might be a name too long problem, but besides that any more
meaningful name by Allen, would be ok with me.
Elias
On 11/8/05, Allen Gilliland <Al...@sun.com> wrote:
> I am okay with this these db changes as well, however I think we should
> rename the comment table to something a little more appropriate, like
> "roller_weblogcomments". We may need to setup different syntax to do
> that for various dbs.
>
> Then as Dave said, I don't think we need any of that stuff for the audit
> log table. That table is new in 2.0, so we just need to alter it's
> definition in the 2.0 createdb.sql file.
>
> -- Allen
>
>
> On Tue, 2005-11-08 at 07:30, Dave Johnson wrote:
> > This patch database schema changes (shown below), so if we don't get it
> > into 2.0, it'll have to wait for 3.0.
> >
> > alter table comment rename to blogcomment;
> > alter table roller_audit_log add column comment_text varchar(255);
> > update roller_audit_log set comment_text = comment;
> > alter table roller_audit_log modify comment_text varchar(255) not
> > null;
> > alter table roller_audit_log drop column comment;
> >
> > The rename syntax is in the docs for MySQL and PostgreSQL. The
> > roller_audit_log table is totally unused at this point, so related
> > changes are not an issue.
> >
> > All in all, the patch looks very safe.
> >
> > Can I sneak it in before 2.0 goes final?
> >
> > - Dave
> >
> >
> >
> > On Nov 6, 2005, at 2:55 PM, Max Rudman wrote:
> >
> > > Hi Dave,
> > >
> > > Sorry for a long delay in getting this to you -- I got busy at the day
> > > job. At any rate, attached is the patch for Oracle compatibility and
> > > db_oracle.properties file. Here are the two main changes I had to
> > > make:
> > >
> > > 1) Updated createdb-raw.sql to change 'comment' table to 'blogcomment'
> > > and 'roller_audit_log.comment' column to 'comment_text' column. The
> > > reason for these is that 'comment' is a reserved word in Oracle 10g. I
> > > also updated XDoclet tags in the appropriate POJOs to have the above
> > > cahnages reflected in Hibernate mapping files.
> > >
> > > 2) Added an Oracle "if" clause to the
> > > HibernateRefererManagerImpl.getDaysPopularWebsites method which runs
> > > the JDBC-based query.
> > >
> > > There are also a few miscellaneous changes to the config files
> > > (build.xml, hibernate.cfg.xml) for obvious reasons. Please review and
> > > let me know if you have any questions.
> > >
> > > I've tested the parts where I made changes against Oracle 10g Release
> > > 2 on Windows. We've also had the app based on Roller code running in
> > > production against Oracle for some time now. However, it only uses a
> > > subset of Roller functionality so I am not sure about more obscure
> > > parts of the codebase.
> > >
> > > Max
> > >
> > > <roller-oracle-patch.txt><db_oracle.properties>
> >
>
>
Re: Oracle patch fro 2.0
Posted by paksegu <pa...@yahoo.com>.
How about naming it as rollerComments that should will do for all various databases
Allen Gilliland <Al...@Sun.COM> wrote:I am okay with this these db changes as well, however I think we should
rename the comment table to something a little more appropriate, like
"roller_weblogcomments". We may need to setup different syntax to do
that for various dbs.
Then as Dave said, I don't think we need any of that stuff for the audit
log table. That table is new in 2.0, so we just need to alter it's
definition in the 2.0 createdb.sql file.
-- Allen
On Tue, 2005-11-08 at 07:30, Dave Johnson wrote:
> This patch database schema changes (shown below), so if we don't get it
> into 2.0, it'll have to wait for 3.0.
>
> alter table comment rename to blogcomment;
> alter table roller_audit_log add column comment_text varchar(255);
> update roller_audit_log set comment_text = comment;
> alter table roller_audit_log modify comment_text varchar(255) not
> null;
> alter table roller_audit_log drop column comment;
>
> The rename syntax is in the docs for MySQL and PostgreSQL. The
> roller_audit_log table is totally unused at this point, so related
> changes are not an issue.
>
> All in all, the patch looks very safe.
>
> Can I sneak it in before 2.0 goes final?
>
> - Dave
>
>
>
> On Nov 6, 2005, at 2:55 PM, Max Rudman wrote:
>
> > Hi Dave,
> >
> > Sorry for a long delay in getting this to you -- I got busy at the day
> > job. At any rate, attached is the patch for Oracle compatibility and
> > db_oracle.properties file. Here are the two main changes I had to
> > make:
> >
> > 1) Updated createdb-raw.sql to change 'comment' table to 'blogcomment'
> > and 'roller_audit_log.comment' column to 'comment_text' column. The
> > reason for these is that 'comment' is a reserved word in Oracle 10g. I
> > also updated XDoclet tags in the appropriate POJOs to have the above
> > cahnages reflected in Hibernate mapping files.
> >
> > 2) Added an Oracle "if" clause to the
> > HibernateRefererManagerImpl.getDaysPopularWebsites method which runs
> > the JDBC-based query.
> >
> > There are also a few miscellaneous changes to the config files
> > (build.xml, hibernate.cfg.xml) for obvious reasons. Please review and
> > let me know if you have any questions.
> >
> > I've tested the parts where I made changes against Oracle 10g Release
> > 2 on Windows. We've also had the app based on Roller code running in
> > production against Oracle for some time now. However, it only uses a
> > subset of Roller functionality so I am not sure about more obscure
> > parts of the codebase.
> >
> > Max
> >
> >
>
Ransford Segu-Baffoe
paksegu@yahoo.com
paksegu@noqturnalmediasystems.com
http://www.noqturnalmediasystems.com/
---------------------------------
Yahoo! FareChase - Search multiple travel sites in one click.
Re: Oracle patch fro 2.0
Posted by Allen Gilliland <Al...@Sun.COM>.
I am okay with this these db changes as well, however I think we should
rename the comment table to something a little more appropriate, like
"roller_weblogcomments". We may need to setup different syntax to do
that for various dbs.
Then as Dave said, I don't think we need any of that stuff for the audit
log table. That table is new in 2.0, so we just need to alter it's
definition in the 2.0 createdb.sql file.
-- Allen
On Tue, 2005-11-08 at 07:30, Dave Johnson wrote:
> This patch database schema changes (shown below), so if we don't get it
> into 2.0, it'll have to wait for 3.0.
>
> alter table comment rename to blogcomment;
> alter table roller_audit_log add column comment_text varchar(255);
> update roller_audit_log set comment_text = comment;
> alter table roller_audit_log modify comment_text varchar(255) not
> null;
> alter table roller_audit_log drop column comment;
>
> The rename syntax is in the docs for MySQL and PostgreSQL. The
> roller_audit_log table is totally unused at this point, so related
> changes are not an issue.
>
> All in all, the patch looks very safe.
>
> Can I sneak it in before 2.0 goes final?
>
> - Dave
>
>
>
> On Nov 6, 2005, at 2:55 PM, Max Rudman wrote:
>
> > Hi Dave,
> >
> > Sorry for a long delay in getting this to you -- I got busy at the day
> > job. At any rate, attached is the patch for Oracle compatibility and
> > db_oracle.properties file. Here are the two main changes I had to
> > make:
> >
> > 1) Updated createdb-raw.sql to change 'comment' table to 'blogcomment'
> > and 'roller_audit_log.comment' column to 'comment_text' column. The
> > reason for these is that 'comment' is a reserved word in Oracle 10g. I
> > also updated XDoclet tags in the appropriate POJOs to have the above
> > cahnages reflected in Hibernate mapping files.
> >
> > 2) Added an Oracle "if" clause to the
> > HibernateRefererManagerImpl.getDaysPopularWebsites method which runs
> > the JDBC-based query.
> >
> > There are also a few miscellaneous changes to the config files
> > (build.xml, hibernate.cfg.xml) for obvious reasons. Please review and
> > let me know if you have any questions.
> >
> > I've tested the parts where I made changes against Oracle 10g Release
> > 2 on Windows. We've also had the app based on Roller code running in
> > production against Oracle for some time now. However, it only uses a
> > subset of Roller functionality so I am not sure about more obscure
> > parts of the codebase.
> >
> > Max
> >
> > <roller-oracle-patch.txt><db_oracle.properties>
>
Re: Oracle patch fro 2.0
Posted by Dave Johnson <da...@rollerweblogger.org>.
On Nov 8, 2005, at 10:43 AM, Elias Torres wrote:
> I'm on ok with sneaking the patch, but there's so much churn in the
> codebase and I feel I have not been spending enough time testing the
> codebase (at least DB compat testing with Derby/DB2). Maybe a heads up
> with enough time for me to do some final testing would be much
> appreciated.
We've been 2.0 running in production (at more than one site) for a
couple of weeks now, so we've been trying to restrict our changes in
the trunk to critical fixes. The one exception to that was the
"intermittent null" fix, we had to turn off class-level lazy-loading in
Hibernate and do some refactoring in the POJO setData(), equals() and
copy constructors to fix that.
We definitely don't want to do a release until we're all comfortable
with the code base. I thought we were getting real close, that's why I
called for a vote.
- Dave
>
> What are the conventions for deciding on release revsion? Does
> Dave/Allen test and that's enough or do others make sure their
> features/responsibilities are working and then release happens only
> until everyone has given a go?
>
> Regards,
>
> Elias
>
> On 11/8/05, Dave Johnson <da...@rollerweblogger.org> wrote:
>> This patch database schema changes (shown below), so if we don't get
>> it
>> into 2.0, it'll have to wait for 3.0.
>>
>> alter table comment rename to blogcomment;
>> alter table roller_audit_log add column comment_text varchar(255);
>> update roller_audit_log set comment_text = comment;
>> alter table roller_audit_log modify comment_text varchar(255) not
>> null;
>> alter table roller_audit_log drop column comment;
>>
>> The rename syntax is in the docs for MySQL and PostgreSQL. The
>> roller_audit_log table is totally unused at this point, so related
>> changes are not an issue.
>>
>> All in all, the patch looks very safe.
>>
>> Can I sneak it in before 2.0 goes final?
>>
>> - Dave
>>
>>
>>
>> On Nov 6, 2005, at 2:55 PM, Max Rudman wrote:
>>
>>> Hi Dave,
>>>
>>> Sorry for a long delay in getting this to you -- I got busy at the
>>> day
>>> job. At any rate, attached is the patch for Oracle compatibility and
>>> db_oracle.properties file. Here are the two main changes I had to
>>> make:
>>>
>>> 1) Updated createdb-raw.sql to change 'comment' table to
>>> 'blogcomment'
>>> and 'roller_audit_log.comment' column to 'comment_text' column. The
>>> reason for these is that 'comment' is a reserved word in Oracle 10g.
>>> I
>>> also updated XDoclet tags in the appropriate POJOs to have the above
>>> cahnages reflected in Hibernate mapping files.
>>>
>>> 2) Added an Oracle "if" clause to the
>>> HibernateRefererManagerImpl.getDaysPopularWebsites method which runs
>>> the JDBC-based query.
>>>
>>> There are also a few miscellaneous changes to the config files
>>> (build.xml, hibernate.cfg.xml) for obvious reasons. Please review and
>>> let me know if you have any questions.
>>>
>>> I've tested the parts where I made changes against Oracle 10g Release
>>> 2 on Windows. We've also had the app based on Roller code running in
>>> production against Oracle for some time now. However, it only uses a
>>> subset of Roller functionality so I am not sure about more obscure
>>> parts of the codebase.
>>>
>>> Max
>>>
>>> <roller-oracle-patch.txt><db_oracle.properties>
>>
>>
>
Re: Oracle patch fro 2.0
Posted by Elias Torres <el...@torrez.us>.
I'm on ok with sneaking the patch, but there's so much churn in the
codebase and I feel I have not been spending enough time testing the
codebase (at least DB compat testing with Derby/DB2). Maybe a heads up
with enough time for me to do some final testing would be much
appreciated.
What are the conventions for deciding on release revsion? Does
Dave/Allen test and that's enough or do others make sure their
features/responsibilities are working and then release happens only
until everyone has given a go?
Regards,
Elias
On 11/8/05, Dave Johnson <da...@rollerweblogger.org> wrote:
> This patch database schema changes (shown below), so if we don't get it
> into 2.0, it'll have to wait for 3.0.
>
> alter table comment rename to blogcomment;
> alter table roller_audit_log add column comment_text varchar(255);
> update roller_audit_log set comment_text = comment;
> alter table roller_audit_log modify comment_text varchar(255) not
> null;
> alter table roller_audit_log drop column comment;
>
> The rename syntax is in the docs for MySQL and PostgreSQL. The
> roller_audit_log table is totally unused at this point, so related
> changes are not an issue.
>
> All in all, the patch looks very safe.
>
> Can I sneak it in before 2.0 goes final?
>
> - Dave
>
>
>
> On Nov 6, 2005, at 2:55 PM, Max Rudman wrote:
>
> > Hi Dave,
> >
> > Sorry for a long delay in getting this to you -- I got busy at the day
> > job. At any rate, attached is the patch for Oracle compatibility and
> > db_oracle.properties file. Here are the two main changes I had to
> > make:
> >
> > 1) Updated createdb-raw.sql to change 'comment' table to 'blogcomment'
> > and 'roller_audit_log.comment' column to 'comment_text' column. The
> > reason for these is that 'comment' is a reserved word in Oracle 10g. I
> > also updated XDoclet tags in the appropriate POJOs to have the above
> > cahnages reflected in Hibernate mapping files.
> >
> > 2) Added an Oracle "if" clause to the
> > HibernateRefererManagerImpl.getDaysPopularWebsites method which runs
> > the JDBC-based query.
> >
> > There are also a few miscellaneous changes to the config files
> > (build.xml, hibernate.cfg.xml) for obvious reasons. Please review and
> > let me know if you have any questions.
> >
> > I've tested the parts where I made changes against Oracle 10g Release
> > 2 on Windows. We've also had the app based on Roller code running in
> > production against Oracle for some time now. However, it only uses a
> > subset of Roller functionality so I am not sure about more obscure
> > parts of the codebase.
> >
> > Max
> >
> > <roller-oracle-patch.txt><db_oracle.properties>
>
>
Re: Oracle patch fro 2.0
Posted by Dave Johnson <da...@rollerweblogger.org>.
This patch database schema changes (shown below), so if we don't get it
into 2.0, it'll have to wait for 3.0.
alter table comment rename to blogcomment;
alter table roller_audit_log add column comment_text varchar(255);
update roller_audit_log set comment_text = comment;
alter table roller_audit_log modify comment_text varchar(255) not
null;
alter table roller_audit_log drop column comment;
The rename syntax is in the docs for MySQL and PostgreSQL. The
roller_audit_log table is totally unused at this point, so related
changes are not an issue.
All in all, the patch looks very safe.
Can I sneak it in before 2.0 goes final?
- Dave
On Nov 6, 2005, at 2:55 PM, Max Rudman wrote:
> Hi Dave,
>
> Sorry for a long delay in getting this to you -- I got busy at the day
> job. At any rate, attached is the patch for Oracle compatibility and
> db_oracle.properties file. Here are the two main changes I had to
> make:
>
> 1) Updated createdb-raw.sql to change 'comment' table to 'blogcomment'
> and 'roller_audit_log.comment' column to 'comment_text' column. The
> reason for these is that 'comment' is a reserved word in Oracle 10g. I
> also updated XDoclet tags in the appropriate POJOs to have the above
> cahnages reflected in Hibernate mapping files.
>
> 2) Added an Oracle "if" clause to the
> HibernateRefererManagerImpl.getDaysPopularWebsites method which runs
> the JDBC-based query.
>
> There are also a few miscellaneous changes to the config files
> (build.xml, hibernate.cfg.xml) for obvious reasons. Please review and
> let me know if you have any questions.
>
> I've tested the parts where I made changes against Oracle 10g Release
> 2 on Windows. We've also had the app based on Roller code running in
> production against Oracle for some time now. However, it only uses a
> subset of Roller functionality so I am not sure about more obscure
> parts of the codebase.
>
> Max
>
> <roller-oracle-patch.txt><db_oracle.properties>
Oracle patch fro 2.0
Posted by Max Rudman <mr...@steelbrick.com>.
Hi Dave,
Sorry for a long delay in getting this to you -- I got busy at the
day job. At any rate, attached is the patch for Oracle compatibility
and db_oracle.properties file. Here are the two main changes I had to
make:
1) Updated createdb-raw.sql to change 'comment' table to
'blogcomment' and 'roller_audit_log.comment' column to 'comment_text'
column. The reason for these is that 'comment' is a reserved word in
Oracle 10g. I also updated XDoclet tags in the appropriate POJOs to
have the above cahnages reflected in Hibernate mapping files.
2) Added an Oracle "if" clause to the
HibernateRefererManagerImpl.getDaysPopularWebsites method which runs
the JDBC-based query.
There are also a few miscellaneous changes to the config files
(build.xml, hibernate.cfg.xml) for obvious reasons. Please review and
let me know if you have any questions.
I've tested the parts where I made changes against Oracle 10g Release
2 on Windows. We've also had the app based on Roller code running in
production against Oracle for some time now. However, it only uses a
subset of Roller functionality so I am not sure about more obscure
parts of the codebase.
Max
Re: help plz! solving the roller 2.0 intermittent "null" bug
Posted by Dave Johnson <da...@rollerweblogger.org>.
On Nov 2, 2005, at 12:25 PM, Allen Gilliland wrote:
> So it sounds like there are a couple options ...
> 1. alter our hibernate mappings to for lazy="false" by default. this
> would require upgrading our xdoclet version.
> 2. alter our pojos to force the use of getters/setters and prevent the
> use of direct accessors.
Assuming we've correctly identified the problem, #2 alone should solve
it.
> personally, i think we should do both, but i would be more adamant
> about doing #2. the standard pojo/bean pattern recommends that
> attributes be private and only accessed through getters and setters
> and i believe we should adhere to that. it seems pretty lame that
> hibernate couldn't deal with direct access, but oh well. with a bit
> of IDE wizardry it shouldn't be too hard to make this happen.
>
> of course it also makes sense that we probably don't need to use lazy
> loading on *all* pojo properties, so defaulting to lazy="false" would
> be a good thing too. i don't know all the details about why that was
> changed in hibernate 3, maybe there is a good reason to use lazy
> loading all the time? maybe this would account for the performance
> improvements you noted on your site Dave?
That's possible, I guess, but I really don't know the answer.
> what does everyone else prefer to do?
I'd prefer to do both #1 and #2 right now, but could be talked into
saving #1 for later.
- Dave
>
> -- Allen
>
>
> On Wed, 2005-11-02 at 06:17, Dave Johnson wrote:
>> On Nov 2, 2005, at 7:44 AM, Dave Johnson wrote:
>>>> Anil wrote:
>>>> Changing the loading behavior in the mappings to be non-lazy one
>>>> should be able to avoid this behavior. If we have a lot of code
>>>> dealing with pojo members directly, we may want to do this. I
>>>> believe the laziness defaults changed between 2.x and 3.x.
>>>
>>> The more involved fix is to upgrade to the latest XDoclet (which may
>>> require building it from CVS to get around that bug that bit me), set
>>> lazy="false" at the class level and set lazy="true" for the
>>> individual
>>> collections that we want to be lazy-loaded (and I think we're already
>>> doing that). We're using XDoclet 1.2b4 and the latest XDoclet is 1.2.
>>
>> I've implemented that more involved fix in my workspace. I upgraded to
>> XDoclet 1.2.3, found a reasonable work-around for that bug I mentioned
>> and set lazy="false" at the @hibernate.class level for all 28 of our
>> POJOS. Roller appears to be working fine in my workspace.
>>
>> There are three reasons why we might want to commit this for 2.0:
>> 1) it solves the intermittent null problem (we need to verify this)
>> 2) it's better to use an official release of XDoclet rather than
>> custom
>> 1.2b4 build
>> 3) it's better to stick with lazy="false" since that's what we were
>> doing before 2.0
>>
>> Since I can't duplicate the intermittent null problem, Allen needs to
>> verify that #1 is a true statement.
>>
>> - Dave
>>
>
Re: help plz! solving the roller 2.0 intermittent "null" bug
Posted by Allen Gilliland <Al...@Sun.COM>.
So it sounds like there are a couple options ...
1. alter our hibernate mappings to for lazy="false" by default. this would require upgrading our xdoclet version.
2. alter our pojos to force the use of getters/setters and prevent the use of direct accessors.
personally, i think we should do both, but i would be more adamant about doing #2. the standard pojo/bean pattern recommends that attributes be private and only accessed through getters and setters and i believe we should adhere to that. it seems pretty lame that hibernate couldn't deal with direct access, but oh well. with a bit of IDE wizardry it shouldn't be too hard to make this happen.
of course it also makes sense that we probably don't need to use lazy loading on *all* pojo properties, so defaulting to lazy="false" would be a good thing too. i don't know all the details about why that was changed in hibernate 3, maybe there is a good reason to use lazy loading all the time? maybe this would account for the performance improvements you noted on your site Dave?
what does everyone else prefer to do?
-- Allen
On Wed, 2005-11-02 at 06:17, Dave Johnson wrote:
> On Nov 2, 2005, at 7:44 AM, Dave Johnson wrote:
> >> Anil wrote:
> >> Changing the loading behavior in the mappings to be non-lazy one
> >> should be able to avoid this behavior. If we have a lot of code
> >> dealing with pojo members directly, we may want to do this. I
> >> believe the laziness defaults changed between 2.x and 3.x.
> >
> > The more involved fix is to upgrade to the latest XDoclet (which may
> > require building it from CVS to get around that bug that bit me), set
> > lazy="false" at the class level and set lazy="true" for the individual
> > collections that we want to be lazy-loaded (and I think we're already
> > doing that). We're using XDoclet 1.2b4 and the latest XDoclet is 1.2.
>
> I've implemented that more involved fix in my workspace. I upgraded to
> XDoclet 1.2.3, found a reasonable work-around for that bug I mentioned
> and set lazy="false" at the @hibernate.class level for all 28 of our
> POJOS. Roller appears to be working fine in my workspace.
>
> There are three reasons why we might want to commit this for 2.0:
> 1) it solves the intermittent null problem (we need to verify this)
> 2) it's better to use an official release of XDoclet rather than custom
> 1.2b4 build
> 3) it's better to stick with lazy="false" since that's what we were
> doing before 2.0
>
> Since I can't duplicate the intermittent null problem, Allen needs to
> verify that #1 is a true statement.
>
> - Dave
>
Re: help plz! solving the roller 2.0 intermittent "null" bug
Posted by Dave Johnson <da...@rollerweblogger.org>.
On Nov 2, 2005, at 7:44 AM, Dave Johnson wrote:
>> Anil wrote:
>> Changing the loading behavior in the mappings to be non-lazy one
>> should be able to avoid this behavior. If we have a lot of code
>> dealing with pojo members directly, we may want to do this. I
>> believe the laziness defaults changed between 2.x and 3.x.
>
> The more involved fix is to upgrade to the latest XDoclet (which may
> require building it from CVS to get around that bug that bit me), set
> lazy="false" at the class level and set lazy="true" for the individual
> collections that we want to be lazy-loaded (and I think we're already
> doing that). We're using XDoclet 1.2b4 and the latest XDoclet is 1.2.
I've implemented that more involved fix in my workspace. I upgraded to
XDoclet 1.2.3, found a reasonable work-around for that bug I mentioned
and set lazy="false" at the @hibernate.class level for all 28 of our
POJOS. Roller appears to be working fine in my workspace.
There are three reasons why we might want to commit this for 2.0:
1) it solves the intermittent null problem (we need to verify this)
2) it's better to use an official release of XDoclet rather than custom
1.2b4 build
3) it's better to stick with lazy="false" since that's what we were
doing before 2.0
Since I can't duplicate the intermittent null problem, Allen needs to
verify that #1 is a true statement.
- Dave
Re: help plz! solving the roller 2.0 intermittent "null" bug
Posted by Dave Johnson <da...@rollerweblogger.org>.
On Nov 2, 2005, at 1:09 AM, Anil Gangolli wrote:
> I suspect this is just Hibernate 3.x behavior with cglib proxies
> around lazy loading. The times when it works is when the fields have
> been loaded already. Using the accessors will always get the fields
> initialized properly.
I hadn't thought of that, but you are right, Hibernate3 is a suspect in
this case. Hibernate now uses lazy loading for simple properties and
defaults to lazy="true"
I suspected this problem with that weird intermittent Planet page error:
http://opensource2.atlassian.com/projects/roller/browse/ROL-843
> Changing the loading behavior in the mappings to be non-lazy one
> should be able to avoid this behavior. If we have a lot of code
> dealing with pojo members directly, we may want to do this. I believe
> the laziness defaults changed between 2.x and 3.x.
I looked into this. Hibernate3 allows a lazy attribute at the class
level and by default lazy="true". There are two reasons why I couldn't
easily set it to false:
1 - The version of XDoclet we're using doesn't support that (I tried to
upgrade the the latest XDoclet, but ran into an XDoclet bug that
prevented upgrade).
2 - I didn't want to turn off lazy loading at the class level, because
for performance reasons we still want it for collections.
As a quick fix, I bet you could change WeblogEntryData.setData().
Change this line:
this.text = other.text;
To this:
this.text = other.getText();
The more involved fix is to upgrade to the latest XDoclet (which may
require building it from CVS to get around that bug that bit me), set
lazy="false" at the class level and set lazy="true" for the individual
collections that we want to be lazy-loaded (and I think we're already
doing that). We're using XDoclet 1.2b4 and the latest XDoclet is 1.2.
Another possibility is to change all of our POJO setData() methods to
use the getters rather than direct access to fields, but that may not
be a as safe as the lazy="false" fix.
- Dave
Re: help plz! solving the roller 2.0 intermittent "null" bug
Posted by Anil Gangolli <an...@busybuddha.org>.
I suspect this is just Hibernate 3.x behavior with cglib proxies around
lazy loading. The times when it works is when the fields have been
loaded already. Using the accessors will always get the fields
initialized properly.
Changing the loading behavior in the mappings to be non-lazy one should
be able to avoid this behavior. If we have a lot of code dealing with
pojo members directly, we may want to do this. I believe the laziness
defaults changed between 2.x and 3.x.
--a.