I agree with the DAO/Register approach but that took my work out of the picture. Why not reverting to a database implementation like before but delegating the db transactions to the DAO classes. Right now implementing a different approach is impossible compared with the replace DB implementation class from previous versions.
Right now I'm stuck in version 2.63 with two options:
1. Stay there and merge important changes from other versions
2. Drop my work of months and stay with core Marauroa
Isn't Marauroa turning from a framework to an implementation specific project?
Am I being unreasonable?
I'm dying for feedback....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1st) There are at least three totally different projects based on Marauroa 3.0: Stendhal (an MOPRPG), Marboard (no game, but a multi user drawing application), and jMaPacman (a skill game).
2nd) I asked for comments in advance and you did notice my posting. So it is a bit unfair to insult me now.
3rd) You did not even describe your problem.
> Why not reverting to a database implementation like before but delegating
> the db transactions to the DAO classes.
I don't understand this sentence because after reverting to 2.x there would be no DAO classes anymore. And the rest of the database code was rewritten to support multi-threading. Multi-threading is already in heavy use so it is not possible to remove this feature.
So what we should do now is this:
* You should describe your problem in detail.
* We should start to think about totally asynchronous database access. My long term goal is to handle up to 2 minutes (in theory unlimited but the risks gets and higher that information is lost so there should be an upper limit) of database lag without any lag in game. Currently database lag above 100ms causes lag in game.
There is a solution for Stendhal's game- and item events. But this is only a first step: game/item-events are write-only data, reading is the difficult part. And of cause we need a solution at Marauroa itself. So that even login of a player with a high lag database does not cause lag in game. This player has to wait before he is placed in world, but all others should not notice this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2009-09-07
First I never meant to insult you at all. If you felt that way I apologize.
1) Those projects did not modify the inner workings of the DB access like mine does so they were relatively easy to prt
2) There are comments from my part. Maybe none against it since it was hard to criticize something without seeing the implementation. In theory there wasn't any problem at all. All came up due to the implementation.
3)My problem is that right now the DB approach is not extension friendly. I suggested using an interface to define the DAO classes so I can use it to extend it. The DAO classes are registered using a class where I suggest a string or enum to be defined.
I have nothing against multi-threading and I understand your work, just need a Marauroa supported way of continuing my work. Maybe mine i the wrong approach and I end using yours at the end.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am sorry, I overreacted when you wrote that marauroa is only for one project after I spent a lot of time to make sure that the impact of my changes is as small as possible for games/applications.
> My problem is that right now the DB approach is not extension friendly.
It is a lot more extension friendly for _users_ of the framework than it used to be. Now it is possible to override smaller classes and easily provide additional DAOs.
> I suggested using an interface to define the DAO classes so I can use it to extend it.
There are two ways of interfaces: One generic DAO interface for create, read, update, delete. This does not work out because most of those operations do not apply to all entities. And there are additional methods required, for example there are different ways to analyze the loginEvent table to detect password cracking.
The other approach is to have one interface per DAO. That is the way we do it at my work. Having those interface might be a bit nicer for framework replacements but the added complexity has no gain for applications.
You can provide your own implementations by extending the DAO classes instead of implementing the non existing interfaces. Since this code only depends on the JDK itself and is reasonable small this is a possible way. This way might not win a beauty contest but it is walkable. An alternative would be to completely replace the provided classes since you have your own marauroa.jar. But this approach is more risky when it comes to keeping the API compatible.
> The DAO classes are registered using a class where I suggest a string or enum to be defined.
An enum cannot be used because applications can register their own DAOs. In the past we did use string a lot but their had been complains that string are not type save, can have misspellings and so on. As a result of those discussions the rpclass of an object is no longer stored as type-attribute as string in the RPObject but RPObjects have a reference to an instance of RPClass.
Because of this change and the associated discussions, I think that using the java class instead of an arbitrary string is a good idea. And since one has to extend the class in order to provide an alternative implementation, the class object is at hand anyway.
At the moment we have in Marauroa:
DAORegister.get().register(CharacterDAO.class, new CharacterDAO());
And in Stendhal:
DAORegister.get().register(CharacterDAO.class, new StendhalCharacterDAO());
public class StendhalCharacterDAO extends CharacterDAO {
...
This would have worked with per-class interfaces as well:
DAORegister.get().register(ICharacterDAO.class, new CharacterDAO());
And in Stendhal:
DAORegister.get().register(ICharacterDAO.class, new StendhalCharacterDAO());
public class StendhalCharacterDAO implements ICharacterDAO {
...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2009-09-09
I understand. It seems reasonable now. I'll stick for now to 2.63 until I get my game stable for a first release. Then I have in agenda upgrading to Marauroa 3.x and moving to use Netbeans RCP for the client (and have some ideas for a db side tool suite) as I'm getting experience at work with it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree with the DAO/Register approach but that took my work out of the picture. Why not reverting to a database implementation like before but delegating the db transactions to the DAO classes. Right now implementing a different approach is impossible compared with the replace DB implementation class from previous versions.
Right now I'm stuck in version 2.63 with two options:
1. Stay there and merge important changes from other versions
2. Drop my work of months and stay with core Marauroa
Isn't Marauroa turning from a framework to an implementation specific project?
Am I being unreasonable?
I'm dying for feedback....
1st) There are at least three totally different projects based on Marauroa 3.0: Stendhal (an MOPRPG), Marboard (no game, but a multi user drawing application), and jMaPacman (a skill game).
2nd) I asked for comments in advance and you did notice my posting. So it is a bit unfair to insult me now.
3rd) You did not even describe your problem.
> Why not reverting to a database implementation like before but delegating
> the db transactions to the DAO classes.
I don't understand this sentence because after reverting to 2.x there would be no DAO classes anymore. And the rest of the database code was rewritten to support multi-threading. Multi-threading is already in heavy use so it is not possible to remove this feature.
So what we should do now is this:
* You should describe your problem in detail.
* We should start to think about totally asynchronous database access. My long term goal is to handle up to 2 minutes (in theory unlimited but the risks gets and higher that information is lost so there should be an upper limit) of database lag without any lag in game. Currently database lag above 100ms causes lag in game.
There is a solution for Stendhal's game- and item events. But this is only a first step: game/item-events are write-only data, reading is the difficult part. And of cause we need a solution at Marauroa itself. So that even login of a player with a high lag database does not cause lag in game. This player has to wait before he is placed in world, but all others should not notice this.
First I never meant to insult you at all. If you felt that way I apologize.
1) Those projects did not modify the inner workings of the DB access like mine does so they were relatively easy to prt
2) There are comments from my part. Maybe none against it since it was hard to criticize something without seeing the implementation. In theory there wasn't any problem at all. All came up due to the implementation.
3)My problem is that right now the DB approach is not extension friendly. I suggested using an interface to define the DAO classes so I can use it to extend it. The DAO classes are registered using a class where I suggest a string or enum to be defined.
I have nothing against multi-threading and I understand your work, just need a Marauroa supported way of continuing my work. Maybe mine i the wrong approach and I end using yours at the end.
I am sorry, I overreacted when you wrote that marauroa is only for one project after I spent a lot of time to make sure that the impact of my changes is as small as possible for games/applications.
> My problem is that right now the DB approach is not extension friendly.
It is a lot more extension friendly for _users_ of the framework than it used to be. Now it is possible to override smaller classes and easily provide additional DAOs.
> I suggested using an interface to define the DAO classes so I can use it to extend it.
There are two ways of interfaces: One generic DAO interface for create, read, update, delete. This does not work out because most of those operations do not apply to all entities. And there are additional methods required, for example there are different ways to analyze the loginEvent table to detect password cracking.
The other approach is to have one interface per DAO. That is the way we do it at my work. Having those interface might be a bit nicer for framework replacements but the added complexity has no gain for applications.
You can provide your own implementations by extending the DAO classes instead of implementing the non existing interfaces. Since this code only depends on the JDK itself and is reasonable small this is a possible way. This way might not win a beauty contest but it is walkable. An alternative would be to completely replace the provided classes since you have your own marauroa.jar. But this approach is more risky when it comes to keeping the API compatible.
> The DAO classes are registered using a class where I suggest a string or enum to be defined.
An enum cannot be used because applications can register their own DAOs. In the past we did use string a lot but their had been complains that string are not type save, can have misspellings and so on. As a result of those discussions the rpclass of an object is no longer stored as type-attribute as string in the RPObject but RPObjects have a reference to an instance of RPClass.
Because of this change and the associated discussions, I think that using the java class instead of an arbitrary string is a good idea. And since one has to extend the class in order to provide an alternative implementation, the class object is at hand anyway.
At the moment we have in Marauroa:
DAORegister.get().register(CharacterDAO.class, new CharacterDAO());
And in Stendhal:
DAORegister.get().register(CharacterDAO.class, new StendhalCharacterDAO());
public class StendhalCharacterDAO extends CharacterDAO {
...
This would have worked with per-class interfaces as well:
DAORegister.get().register(ICharacterDAO.class, new CharacterDAO());
And in Stendhal:
DAORegister.get().register(ICharacterDAO.class, new StendhalCharacterDAO());
public class StendhalCharacterDAO implements ICharacterDAO {
...
I understand. It seems reasonable now. I'll stick for now to 2.63 until I get my game stable for a first release. Then I have in agenda upgrading to Marauroa 3.x and moving to use Netbeans RCP for the client (and have some ideas for a db side tool suite) as I'm getting experience at work with it.