Just want to drop a note and say that DB access would make the project very interresting and might attract more people to SGS.
There is quite a lot debate going on here. What i am suggesting is that we could do a GSQL like the hibernate did, they used HQL which at last is tranlsated into SQL language and get executed on whatever the DB server is. Maybe we can define our G query language and when we needed to execute it, we translate it into SQL and get execute than get the recordset we need again package it into GLOs and send back to the server program.
not sure why you would want an other QL appart from legal issues, binding, control… ok so maybe there are some issues 
anyways if your gonna do anything with your data you want it in javabeans anyways and since you want to tell of which type those are suppose to be you want a differend QL already. there is no overhead using orm, since doing fancy stuff directly and writing it performand is gonna be so error prone your game won’t be released, duke nukem forever baby. tis mapping you create a projection of the relational database not a duplicate. and even going with that approch sql still doesn’t need to be hidden as hibernate has proved. also hibernate doesn’t do anything new as far as the database specialist is concerned. even so hibernate still allows you to overide. it’s trival steps put togetter and allowing the programmer to easely use it, no non-natural flavors or colors added.
hibernate is hardly new is so old that these theys we even have a specification the JPA Java persistence api, and I’ve just noticed how it also includes the Java Persistence query language
JPQL apprently.
(I’m having a hard time finding the actual/official specification)
Well, I see two camps emering here. Im wondering if maybe they don’t both have merit…
One camp is looking for more advanced searchign in the GLO database. Argument here is that it makes the GLOs more useful and valuable.
The other really wants to be able to fully integrate with a modern RDBMS. Argument ehre is that for hravy database type activity, the RDBMS model is well understood and developed and SQLhas evolved to really be a power-hosue tool that you wouldnt want to have to go and completely re-invent.
On the latter, my mind is spinning at the moment towards something that allows JDBC use from inside SGS events. The issue here is that SGS events shouldnt block but queries generally do… the solution for that as applied to other things like scoket usage is to have the querey spin off asynchronously and star ta new task when the answer returns…
Thoughts?
On the other, I thin kwe probably still need to explroe some on what kind of search is really required. “Full Javaspaces” is an easy answer, but it cpmes with a bunch of other GLO restrictions Im not sure yet we want to inherit from JavaSpaces…
Returning the result-set to a different task is good for query-only access, because there is no problem with transactional-safety. This could be done with the current version of the SGS also using the raw sockets from the SimTask object. There is no real problem as long as you dont need to work and manipulate both, database tupels and the objectStore in a way which ensures transactional-safety. Where changes to the objectStore are only made if all changes to the database are made valid at the same time … or if the SimTask needs to be aborted, all the database manipulation is rolled back also. This is the problem to solve and if you try to do that in different tasks it will become really nasty fast, because you need methods to ensure and repair consistency of both storages, database and objectStore, if one or the other of both tasks has failed but the other was valid and made permanent already.
Ragosch
Hmm Isee the abort issue, though an abort shoudl result in it gettign rescheduled.
MAYBE what we need is some kind of JDBC tranasactio nwe can pass betwen the tasks to keep a JDBC transaction oepn until all the GLOs tuff completes and then be set to commit as aprt of that final event’s commit…
… let me think some more and as always Im wide open to suggestiosn of other approaches…
This comes near to a solution, because it creates a kind of combined task (consisting of 2 separate SimTasks) which continues using the already open and not yet commited transaction. My first idea was to have GLOs which can be put to sleep after a DB request and get activated again when the results are available, not counting the sleep time as active GLO time (a longer sleep would not cause an abort). Your idea now is something similar to that, because the combined task “sleeps” inbetween the commit of the first task and the activation of the second one. Nevertheless when the second task is started the first one is already made permanent and would need some kind of correction if the second one is aborted due to an issue - that is why I said “comes near to a solution”.
Such a correction would be kind of difficult, because who should do that?- The second task cant, because it is the one which was aborted. A possible solution would be a kind of exception handler GLO … but now it starts to get more complicated than using a single task with overall transactional safety IMO.
Ragosch