In gmane.comp.python.sqlalchemy.user, you wrote:
> --=-QALfoiit8f0M60C7Zms+
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Wed, 2010-07-28 at 17:17 +0000, Faheem Mitha wrote:
>
>> Hi Lance,
>>
>> On Wed, 28 Jul 2010 06:45:30 -0500, Lance Edgar <lance.ed...@gmail.com>
>> wrote:
>> > --=-dKyzuPx4woj1H0B5IT48
>> > Content-Type: text/plain; charset=ISO-8859-1
>> >
>> > On Wed, 2010-07-28 at 11:33 +0000, Faheem Mitha wrote:
>> >
>> >> On Wed, 28 Jul 2010 15:17:09 +0530 (IST), Faheem Mitha
>> >> <fah...@email.unc.edu> wrote:
>> >> >
>> >> > Hi,
>> >>
>> >> > When calling create_all on a metadata instance after a session has
>> >> > alrady been opened causes the create_all to hang, I assume because
>> >> > the session is blocking the create_all. Is there some way to get
>> >> > create_all to use the existing session, or any other graceful way
>> >> > around this? Thanks.
>> >>
>> >> > I guess another option is to close and then reopen the session after
>> >> > the create_all has been called, but I'd prefer not to do that if
>> >> > possible.
>> >>
>> >> Puting a session.close() before the create_all fixes the problem. I
>> >> assume this means that create_all doesn't work in the middle of a
>> >> transaction, or something like that?
>> >
>> >
>> > I can't speak to the underlying mechanics of create_all(), but calling
>> > session.close() prior to create_all() would work, as you say. Another
>> > option would be to simply not use a session, but instead just a
>> > *connection*. Sessions are specific to the ORM which, according to the
>> > code you posted, you are not using. So if you really just need to make
>> > a SELECT call to a table, then instead of creating a session and
>> > calling .execute() on it, you could instead do this:
>>
>> > db = create_engine(dbstring)
>> > meta.bind = db
>> > db.echo = 'debug'
>> > make_foo(meta)
>> > meta.create_all()
>> > db.connect().execute("select * from foo;")
>> > make_bar(meta)
>> > meta.create_all()
>>
>> The example was just an example. After going back and forth a bit,
>> I've finally standardized on session as the thing to more around in my
>> application. The db.connect thing works, I think, because autocommit
>> is the default for connect.
>>
>> I'd like to hear an explanation of why create_all is blocked here. I
>> periodically have my scripts hang for no apparent reason, almost
>> always because the db is blocking something, so would like to become
>> more educated on this issue.
>
>
> Are your sessions contextual (created with scoped_session()) ? Not sure
> what kind of project you're working on (i.e. if you need a contextual
> session or not), but I use sessions and also have to create tables on
> the fly occasionally...but my sessions aren't contextual and I always
> create and close them immediately when finished. See "When do I make a
> Session ?" at
> http://www.sqlalchemy.org/docs/session.html#frequently-asked-questions
I'm not curently using scoped_session, but plan to be in a bit,
because I'll try doing some multi-threading. Though I honestly have
only the foggiest idea what scoped_sesion is doing. I could close and
open the sessions, sure, but it seems easier just to pass around one
session between functions within my application, which reads and
writes stuff to one specific set of tables in one pass. Opening and
closing is just extra overhead.
I gather that session is an ORM thing, and I'm using some ORM
stuff. However, I could probably manage with just psycopg2, though it
wouldn't be pretty.
> But I also apologize if I'm telling you nothing new, certainly don't
> mean to insult. Just trying to help.
My understanding of the underlying technical details of SQLA is quite
fuzzy, so feel free to explain the obvious to me anytime. I might
learn something new. Thanks for your help.
> I assume Michael will have to explain the blocking thing, but FWIW I
> couldn't reproduce that issue while using SQLite or MySQL, so it
> might have just as much to do with PostgreSQL as anything
> else...whether that means its SA dialect or the server configuration
> itself I couldn't say.
Hmm. That's interesting.
Regards, Faheem.
--
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.
