On Fri, Jan 10, 2014 at 10:55 AM, Paul Moore <[email protected]> wrote:
> On Friday, 10 January 2014 16:27:12 UTC, Kevin H wrote:
>
>> It sounds to me like the problem you're having has to do with how you are
>> getting the reference to the package, which isn't shown in your example.
>> How are you getting it?
>>
>
> The new_release() function is what I do - I create a new Package object. I
> was under the impression that when I did a session.merge() that would match
> up existing objects. I'm probably being naive in that, though...
>
I don't think merge() does what you think it does. (Beware...I don't ever
really use it, so I am not an expert in it's use). My understanding is
that merge takes an "input" instance, looks it up or creates a new instance
based on the primary key of the input instance, and copies data from the
input instance to the lookedup/created one, and then returns that. If your
input instance doesn't have a primary key...well, that doesn't seem to make
sense and I really don't know what happens. maybe this is the root of your
problem?
Personally, I stay away from merge() if at all possible, since it can be
way more complex than I want to deal with.
I would recommend trying to do things in the simplest way you can get away
with, and see whether that can help you increase your understanding. Try
using add() and see if that helps you grok a bit more.
> The session doesn't do anything "by magic", even if it seems that way
> sometimes. It just manages things behind the scenes.
>
> Hmm - managing things behind the scenes is what I was meaning by "magic".
> The problem is that I can't find any clear reference about what is, and
> what is not, managed behind the scenes. As I said, it's more about my
> understanding (and hence about me knowing what code I need to write) than
> about SQLAlchemy doing anything "wrong".
>
>
>> If you want a new Package, create a new Package object. If you want an
>> exisiting package, query for it. Just like you would in bare SQL code.
>>
>> If you don't know which you need, try searching and create it if it isn't
>> found. I usually do something like:
>>
>> try:
>> pkg = session.query(Package).filter(<condition-goes-here>)
>> except sa.orm.exc.NotFound:
>> pkg = Package()
>> # populate attributes and add to session
>>
>
> OK. That's essentially what I was hoping to avoid. Largely because of that
> query - I may not yet have committed the package to the database.
>
I don't think it has to be committed yet, it just has to exist in the
session. See below.
> For a more extended example, suppose I do the following:
>
> p = Package("pip")
> session.merge(p) # I could do "session.add" here, but I'm not 100% clear
> why just doing merge isn't better in case I'm not sure if pip is already
> present
>
Because p doesn't have a primary key yet? I'm kind of guessing...but I
really think you need a pkey on the input object to merge().
> Somewhere a little later, in other code where I haven't committed yet, but
> I don't have a reference to p available:
>
> r = Release("1.5")
> r.package = Package("pip")
>
> Can I query for "pip" here? There's been no commit yet, and there may not
> even have been a flush (I've had problems with null foreign keys so I've
> had to force autoflush off in a few places). Essentially, will a query
> locate an object that's in session.new but which hasn't been flushed to the
> database yet?
>
>
If you use session.add() then yes, you can query for pip there. The ORM
will find it. On Postgres, at least, it seems that when you add it to the
session, it grabs a value from the sequence used for the primary key, but
doesn't yet add the actual "row" (in this case...other cases might be more
complex) for the package. So the session "knows" what the primary key will
be once you commit the package, and can use that to find the package.
At least that's how it looks like it works, and how I think about it. I
don't claim to know what it actually does.
> This is the crux of my issue. I really don't understand why I'm getting
> null foreign keys on autoflush, but switching autoflush off seems to fix
> it. But maybe that's what's giving me these issues, so maybe I need to turn
> autoflush back on. But then what do I do about my noll FKs?
>
I'm not sure what to say about this. Probably we're hitting the limits of
my understanding here.
> Unfortunately (fortunately?) the SQLAlchemy docs are good enough that
>> there isn't a huge impetus for people outside the project to write
>> tutorials, blog posts, etc. I'd like to see more of that kind of thing as
>> well, but everyone has limited time, I guess.
>>
>
> Without wishing to seem critical, I find the ORM docs pretty difficult to
> follow. They seem to jump around between schema design (DDL) and usage
> (select and DML) in a pretty haphazard fashion, and the information about
> transactional control and session management seems to be spread around the
> various sections. That's basically just my perspective, and may reflect my
> experience, but it is frustrating. Agreed entirely about people having
> limited time, and the docs are certainly far better than a lot that's
> around.
>
I felt the same way back when I started using SA. What fixed it for me was
to go through the ORM tutorial as it is designed to be used, which (and I'm
not sure this is actually explicitly stated anywhere) is to open a python
interpreter and type in the commands, starting at the top, as you read. I
don't know whether that will help you, but it might be worth a shot.
Maybe I'll just have to have a thorough read of the docs before I carry on
> coding. Feels like I'm making more problems than I'm solving right now. Or
> maybe stick to what I know and drop back to the SQL core stuff.
>
There's certainly nothing wrong with using the SA Core, if that's what
you're more comfortable with. Even just using the core is a big win over
using bare SQL IMO, since it makes it much easier to dynamically generate
complex queries (and makes your code more portable across databases, at
least potentially, if you care about that).
> Thanks for the help,
> Paul
>
> --
> You received this message because you are subscribed to the Google Groups
> "sqlalchemy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/sqlalchemy.
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
--
Kevin Horn
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/groups/opt_out.
