This will probably help:
def addToTable():
"""Very simple SQLAlchemy function that populates the Student,
Project
and Supervisor tables."""
for student in students.itervalues():
session.add(student)
session.flush()
for project in projects.itervalues():
session.add(project)
session.flush()
for supervisor in supervisors.itervalues():
session.add(supervisor)
session.flush()
session.commit()
def resetData():
"""An essential helper function to help reset all student, project
and
supervisor data to their pre-allocation values"""
for student in students.itervalues():
student.allocated_project = None
student.allocated_proj_ref = None
student.allocated_rank = penalty
for supervisor in supervisors.itervalues():
supervisor.loading_limit = supervisor.original_quota -
supervisor.predecr_quota
for project in projects.itervalues():
project.allocated = False
project.blocked = False
So yes, my resetData function will revert _certain_ attributes for
only the Student, Supervisor and Project classes back to the state
they were in when I parsed them in from the text files. My students,
supervisors and projects dictionaries -- at the end of the entire M-C
-- will basically look like that. But if there are other attributes I
have not reverted, they won't change. For example my student has an
attribute called "overall_proby" which I get after calculating the
statistics from the M-C simulation. This won't change until I run the
entire simulation from start to end or terminate. However, his
"allocated_project" will remain None.
> If it resets
> student-project associations, then could it end up deleting the
> temp_allocs you just added in that trial?
temp_alloc belongs to the SimAllocation class so resetData() shouldn't
affect it.
> If you were to do this, you would not want to use a
> single global session, because sharing a session between threads
> is a big no-no.
Why is that a bad thing? And how can work around this single global
session? Basically, say in my GUI, I hit "RUN" for the Monte-Carlo
simulation and it does its work. And then I accidentally hit "RUN"
again. It'll recalculate everything right? Now when I click "STATS" to
get my statistics, I'll want to get the statistics for the second time
I ran the simulation. Thus how can I work around the "single global
session" problem?
> It seems like you would get duplicate primary keys on SimAllocation
> rows after the 1st call.
Once again any ways of avoiding this? I some sort of unique key for
the Monte-Carlo runs and have the incrementing row number was the only
thing I can think of since student ID's will repeat after every
individual trial is done.
Oh also: a BIG thank you for taking the time to help me out! I'm
almost at my deadline :)
On Jun 6, 4:39 am, Conor <conor.edward.da...@gmail.com> wrote:
> On 06/05/2010 08:06 PM, Az wrote:
>
>
>
> > Cheers!
>
> > Creating a new instance of my mapped class and settings, manually.
> > Gotcha. I think this will be an easier solution for me.
>
> > Nah, I'm not in a web framework.
>
> > Additional Q:
>
> > +++
>
> > Currently, my database is being stored in memory and it's fine like
> > that since a) my data isn't very expansive and b) I'm running the
> > program (python Main.py) from a command line where I can just comment
> > out various functions in my Main file. However, I'm now designing a
> > GUI for my code where I want to be able to call each function
> > manually. Now, all functions that reference the session will reference
> > "session" I defined as:
>
> > Session = sessionmaker(bind=engine)
> > session = Session()
>
> > Thus after I run my finish my monteCarloBasic (defined way up at the
> > top), I'd probably hit another button that would do what I did for
> > CODE 2, i.e.
>
> > def checkFor4545(trials):
> > sid = 4545
> > print sid
> > project_id_list = list(students[sid].preferences)
> > for project_id in project_id_list
> > gotcha =
> > session.query(SimAllocation).filter(SimAllocation.student_id ==
> > sid).filter(PP.SimAllocation.alloc_proj == project_id).count()
> > print project_id, gotcha/trials
>
> > This basically counts the number of times student 4545 got each of his
> > projects for entire Monte-Carlo simulation and prints the average over
> > the trials.
>
> > So basically when I'm in command line mode and go "python Main.py" my
> > Main looks like:
>
> > trials = 100
> > monteCarloBasic(trials)
> > checkFor4545(trials)
>
> > So those will run one after the other.
>
> > Now when I've got a GUI, I'll have the Monte-Carlo run separately and
> > then afterwards, hit a button that corresponds to
> > 'checkFor4545(trials)'. Now, the reason I used SQLAlchemy in the first
> > place (besides the general usefulness of SQL) is for data persistence.
> > Will 'checkFor4545(trials)' display the same output as it would if it
> > were run serially from Main.py? Will it reference the same "session"?
> > (Probably a question you'll want to slap your forehead over, but I
> > just want to verify I've got my understanding correct).
>
> I see nothing that indicates that they would NOT see the same session,
> but I do have some comments:
>
> * GUIs usually run long tasks in background threads to keep the UI
> responsive. If you were to do this, you would not want to use a
> single global session, because sharing a session between threads
> is a big no-no.
> * I'm concerned what the call to resetData does. If it resets
> student-project associations, then could it end up deleting the
> temp_allocs you just added in that trial?
> * What should happen if you run monteCarloBasic multiple times? It
> seems like you would get duplicate primary keys on SimAllocation
> rows after the 1st call.
>
> > Additionally, when I save to a physical database file, what happens
> > everytime I run monteCarloBasic(trials) (since it writes to the
> > database). Will it rewrite it every time? Or will it keep appending to
> > it?
>
> I don't see anything that would indicate rewriting the database in the
> code that you have shown (except maybe as a side-effect of your
> resetData function that I noted above). Also, you may get duplicate
> primary key errors like I mentioned above.
>
> -Conor
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
