I have a couple additional changes that I think should be part of this
process ...
1. Remove some old classes.
src/org/roller/business/PubTimeData.java
src/org/roller/business/hibernate/Messages.java
src/org/roller/business/hibernate/HibernatePersistenceSession.java
src/org/roller/business/hibernate/messages.properties
src/org/roller/business/HitCountData.java
we don't need the PersistenceSession thing anymore because Hibernate 3.1
handles Session/Transaction scoping via thread local storage for us.
the other classes don't seem to be used anymore.
2. Remove user role CRUD methods from UserManager
since roles are strictly an attribute of a user, then we have no real
reason to allow direct CRUD methods on that data. i have checked the
code an the only methods which currently use these methods are the
grantRole() and revokeRole() methods of UserData. with hibernate we can
simply set the cascade option for the set of roles in UserData to
"all-delete-orphan" and then all you do is grant/revoke a role and then
save the user.
i have tested this and it works nicely. does anyone object to this
approach?
3. Remove PersistenceStrategy interface.
after beginning to work on the backend refactorings i found that the
PersistenceStrategy was actually causing some problems because even
though it is meant to be simple it forces some of its own ideology about
how persistence should be implemented. in particular the
PersistenceStrategy methods do not identify what the transaction
strategy for those methods are, meaning are they commited after being
called? or not? and since the abstract manager impls actually use
those methods there is the potential for a mixup.
my belief is that the implementor of a given backend implementation
should be allowed to do persistence any way they want, as long as they
fully implement all the methods defined in the manager interfaces. so
for this reason i think it makes sense to not force the use of the
PersistenceStrategy.
keep in mind that this is a little hard to describe and i believe it
becomes a little more clear once you get into the code and see what is
happening. also note that i still intend to keep a
HibernatePersistenceStrategy class because it does fit nicely with a
hibernate implementation, but it is more like a Hibernate utility class
rather than a required part of all persistence implementations.
this is a pretty busy week for me, but i hope to have some code
committed to the roller-newbackend branch either late this week or early
next week.
-- Allen
David M Johnson wrote:
done - Dave
On Apr 2, 2006, at 2:59 PM, Allen Gilliland wrote:
Dave,
can you create a branch for "roller-newbackend" when you get a
chance? i'd like to start working on this.
-- Allen
Allen Gilliland wrote:
I don't think we need to involve Spring for any of these
modifications. Migrating to Spring is a separate step.
-- Allen
Max Rudman wrote:
Hi Allen,
Have you looked at Spring transaction management support yet? Your
proposal doesn't address how you plan to implement multi- step
operations and I think Spring can really help you there. I am
more than happy to help with getting that to work.
Max
On Mar 27, 2006, at 2:17 PM, Allen Gilliland wrote:
David M Johnson wrote:
On Mar 27, 2006, at 1:04 PM, Allen Gilliland wrote:
so we would be pushing the logic outside the persistence layer
and expecting someone else to do authentication/authorization,
not the persistence layer.
I agree that somebody else should do the authentication, but the
rules about who can do what (authorization) are part of the
application logic of Roller. The more of that we can encapsulate
the better.
Having said that, I can't object to ripping out setUser() and
getUser(). Currently, we double check things. The presentation
layer calls an "is user X authorized to perform action Y on
object Z" style method and then, in the save() method in the
back-end does another check -- but by that time it's too late,
the change has already been made to the persistent instance.
Ripping out the setUser() and getUser() methods will only affect
that second check that the back-end does -- so it's fine by me.
Are you going to leave the existing "is user authorized to edit"
methods in place so that checks can be made from the
presentation layer as they are now?
i'm not sure exactly what methods you are talking about, are you
talking about the PersistentObject.canSave() methods?
i don't think there is any problem with leaving those in place
right now, but i think long term we can come up with a better
solution.
-- Allen
- Dave
