Persistance Mechanism
Status: Alpha
Brought to you by:
mattj
Menu
▾
▴
I noticed that you've currenlty hardcoded storage for MySQL and have an open bug to remove the SQL from the class to genericize it. I was wondering if you ever thought about using the filesystem for storage as well. You could create an abstract Persistence class then subclass for things like FilePersistence and DatabasePersistance. Possibly a RelationalPersistence and ObjectPersistence if you wanted to go that far. The Database/RelationalPersistence class could actually hold the sql since that should be pretty much the same for all relational db's when using the jdbc interface.
Nice thing about this approach is that you could just do it for the db stuff now and the others later. Or never do any others and have other people do them for you or themselves, kind of like a plug in system for whatever kind of persistence that they wanted, could even create an DirectoryPersistence class.
Just my $0.02, what do you think?
I like the general idea of plug-in architectures to abstract things. And in a Java server it's nice and easy to load a new (plug-in) class at runtime. In the case of persisting the messages, would you envision that the file-based or directory-based mechanisms would eventually be able to support concurrent use, transactions with rollback, etc.? (If not they may still have applications; can you identify a usage case?)
p.s. - the bug as written has been resolved now. All SQL calls are now pulled out into /org/openqueue/passamaquoddy/oq_sql_dialect.conf. This can be abstracted further by turning these SQL calls into method calls on an object, if you can define a persistance model. Interested in tackling it? :-)
Concurrent use/rollback should not be a problem.
I'll take a look at modelling these but I need some information from you. I can look through the code, which I'm doing now, to figure out the current requirements that need to be implemented by this. I would actually rather have you give me the requirements that you want, now and future.
Another thing to think about is if these classes should live in the process space of the OQServer or be in another server, call it the PersistentServer, and have the OQServer communicate with it someway. There are advantages/disadvantages for both, but for now I would say keep it in the OQServer until at least the RDBMS and File classes are implemented and running.
What do you think?
I'd generally say look at the new file oq_sql_dialect.conf to see the scope of inserts, updates, and selects that would need to be done with any persistance mechanism. On top of that, something similar to JDBC result sets might be needed, so code can step through results as needed. And if the persistance mechanism can support some kind of query language (like SQL), that will make it easy to add functionality later, in the form of additional queries.
To me that seems like a difficult project, but if it seems doable to you I can come up with more formal requirements. [You might also look at another thread I just started, called "Things Folks Could Work On" ( http://sourceforge.net/forum/message.php?msg_id=25580 ), which lists small- to large-scale projects that could be done. There are many opportunities to break new ground here, I think.]