On Mar 18, 2011, at 12:25 PM, Sebastian Elsner wrote:
>>> So, using MySQL with max_connections = 100 I quickly run out of
>>> connections, because every client is using about 6 connections, one for
>>> each dialog window, which has its own session instance.
>>
>> seems like an architecture that could use some trimming....
>>
>
>
> Yes, you are probably right.
> But what if I have two dialogs open, change data in both and click apply on
> the first (so it commits the changes). If both had the same session instance,
> which was passed from the main window, the second dialogs changes would also
> be committed, although the user might have wanted to discard them/rollback .
> Is there an alternate way of doing this?
Right I was telling folks at Pycon that dialog windows should probably not
represent session state directly, there would be detached state associated.
The state would then be merged back into a single session using merge(). If
you'd like to raise on a conflict, versioning can be used - this was fixed in
0.7 so that when a stale version is passed in via merge(), an exception is
thrown. In the GUI app, some local-in-memory versioning scheme can be used
between dialog windows, possibly via timestamps.
Other things to consider:
1. multiple, mutating, non-modal dialogs is a bit unusual (never seen
that before)
2. the MVC paradigm, which applies exactly to a graphical app, implies
that a change in one dialog would send an event to all other windows. The
conflict between dialog A and B would be immediate via this system, as the
submission of "A" would send the event to "B", "B" sees pending changes and
alerts. This state, as well as that a text field was changed, should be
maintained by the application through the association of state with each
graphical window and each graphical control. Repurposing the ORM's session
object to handle this is a very limiting approach, as the session is intended
to maintain an interaction with a live database connection only - the
intricacies of user interactions aren't really covered by its state management.
>
> --
> 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.
>
--
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.
