On 06/08/2010 10:54 PM, Az wrote:
>> memo = {}
>> copied_students = copy.deepcopy(students, memo)
>> copied_supervisors = copy.deepcopy(supervisors, memo)
>> copied_projects = copy.deepcopy(projects, memo)
>>
>> After you do this, memo will contain a record of all copied objects. You
>> should examine memo.values() to see if it is copying more than you
>> expected. If it did copy just what you expected, then my worries were
>> unfounded.
>>
> I'll let you know how that turns out soonish. While I know it's my
> data, is there anything you can suggest from your experience that you
> consider to be "unexpected"?
>
Expected: students, supervisors, projects, dictionaries of said objects,
and other attribute values (strings, ints, lists, etc.). Unexpected:
anything else, especially sessions, InstanceState objects, or other ORM
support objects.
>> Yes, session_id/trial_id and stud_id can repeat, and you can still group
>> things together by run_id. Alternatively, you could add an
>> autoincrementing primary key to SimAllocation, but I believe it is
>> redundant since the combination (run_id, session_id/trial_id, stud_id)
>> should be unique anyway. run_id can definitely be a datetime, but I'm
>> not sure how well sqlite (it sounds like you're using sqlite) supports
>> datetimes in queries
>> (seehttp://www.sqlalchemy.org/docs/reference/dialects/sqlite.html#date-an...).
>> A GUID (or UUID) is just a 128-bit value (usually random); the benefit
>> here is you can generate it on the client side and be confident that it
>> will be unique on the server (to avoid duplicate primary key errors).
>> Using datetimes or database sequences would also work. You can
>> definitely pass the run_id as an argument to monteCarloBasic, or to each
>> object's create_db_record method.
>>
> Also I get why you mention three keys: run_id/guid/uuid and session_id/
> trial_id alone won't suffice... but since we know there are unique
> students (within each single allocation run, etc. So I can get rid of
> the "ident" then? It serves no other purpose really if I can get a key
> combo that's unique and works for.
>
Yes, ident is redundant if you have those three columns.
> I am indeed using SQLite3. I take it take my physical database has to
> something like:
> engine = create_engine('sqlite:///Database/spalloc.sqlite3',
> echo=False)?
>
Looks good.
> Also I take it I should generate the UUID (http://docs.python.org/
> library/uuid.html) when I call the MonteCarloBasic function right?
> Since it should be the same for each "call", I take I'll have to
> generate it before the loop. Additionally, how would I actually query
> a 128-bit value? Say I have a bit in my GUI where the supervisor can
> put in a UUID to pull the data off the Database. How would he actually
> know which UUID to put in? Any ideas?
>
Yes, one UUID generation per call to monteCarloBasic. As for knowing
which UUID to query on, you can always query distinct values of the
run_id column, e.g.
session.query(SimAllocation.run_id).distinct().all(), and present them
as a list to the user. However that doesn't really help people know
which UUID to use. Using timestamps (i.e. columns of type
sqlalchemy.DateTime) instead of UUIDs for SimAllocation.run_id may
improve that situation.
> Also once I've got my stuff in the physical database and after my
> program is done, I'd call session.close() right? How do I access the
> DB data then? Would I have to write some separate functions that allow
> me to access the data without using (for example)
> 'session.query(Student)...`? This way the user (i.e. my supervisor)
> won't have to keep running the readData, monteCarloBasic, etc
> functions just to access the DB (that would be poor indeed!).
>
My impression is that readData is only used to import/migrate data into
the database, and that you wouldn't call it very often.
Calling session.close() is not necessary if you have a single global
session like you do. You only need it if you are worried that the
database might get modified concurrently by another transaction (from a
different process, session, etc.). Having said this, session.close()
does not prevent you from using the session later on: it just closes out
any pending transaction and expunges all object instances (including any
student, supervisor, and project instances you may have added/loaded).
This ensures that it sees fresh data for any future queries.
In conclusion, using session.query(Student)... should work whether you
have run monteCarloBasic or not.
-Conor
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
