Thanks for the ticket 1681 consideration. Though my understanding of
the software isn't strong enough to recommend (or understand) what you
are suggesting in 1681, I can observe the behavior enough to wonder
why do we need to go back to the database again?
(Also, wondering if some databases
After merge() returns, is there a way for me to pair each object in
the returned merge_obj with the object it was created from?
For example:
merged_obj = session.merge(object)
At the top level, it is trivial, merged_obj was created because of the
instance object
For single RelationProperties
what circumstances will obj be None?
On Feb 10, 3:30 pm, Michael Bayer mike...@zzzcomputing.com wrote:
On Feb 10, 2010, at 2:49 PM, Kent wrote:
After merge() returns, is there a way for me to pair each object in
the returned merge_obj with the object it was created from?
For example
Very good, thanks.
Although, I'm pretty sure I understand what you are saying, what
exactly do you mean by pending/transients?
On Feb 10, 4:13 pm, Michael Bayer mike...@zzzcomputing.com wrote:
On Feb 10, 2010, at 3:52 PM, Kent wrote:
If I understand you correctly, you are saying
with the original instances, correct (regardless of whether it is a
newly created object or was get()'ed from the database)?
Correct?
On Feb 10, 4:28 pm, Kent k...@retailarchitects.com wrote:
Very good, thanks.
Although, I'm pretty sure I understand what you are saying, what
exactly do you mean
]
{'orderdetails_orderid': 'KBORDE', 'saleprice': 65,
'orderdetails_lineid': 1}
On Feb 10, 9:59 am, Michael Bayer mike...@zzzcomputing.com wrote:
On Feb 10, 2010, at 8:36 AM, Kent wrote:
I've researched this in the past and they don't. I will look into
re-introducing allow_null_pks as a new flag
On Feb 10, 6:59 pm, Michael Bayer mike...@zzzcomputing.com wrote:
On Feb 10, 2010, at 4:36 PM, Kent wrote:
Further, if I inspect the returned object *directly* after the call to
merge(), then aren't I guaranteed any Relations with use_list=True
have will have the same length, since
query the database.
merged.orderdetails[1].saleprice
=
Thanks in advance,
Kent
On Feb 8, 9:57 pm, Michael Bayer mike...@zzzcomputing.com wrote:
On Feb 8, 2010, at 4:12 PM, Kent wrote:
Ok, here are my questions
Ah ha. Thanks for tracking that down, makes sense.
On Feb 9, 2:25 pm, Michael Bayer mike...@zzzcomputing.com wrote:
Kent wrote:
I am on version 0.5.8.
part of your issue is this:
line1.lineid = '15'
should be this:
line1.lineid = 15
This because the value comes back from the DB
Maybe you're still looking into that, but I still don't understand why
this:
merged.orderdetails[0].saleprice
causes a new issue to the database.
(Also, wondering if some databases allow a primary key to be null...)
Thanks again.
On Feb 9, 2:50 pm, Kent k...@retailarchitects.com wrote:
Ah
,
since merge is going to look up the data anyway.
I was hoping I might be able to extend Session or override its
behavior so as to keep a copy of the object returned from .get()
before it merges the changes.
Input and ideas for me?
Thanks very much in advance,
Kent
On Feb 6, 5:47 pm, Michael Bayer
You guys have done some great work, thanks. (How many developers are
you?)
On Feb 8, 11:50 am, Michael Bayer mike...@zzzcomputing.com wrote:
Kent wrote:
Thank you again for your response and time.
I think a different approach may be better for me, but was hoping for
your input.
I
a fetch from the database? It already detected this was a new
record during the merge.
Thanks in advance.
Kent
--
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
There might/probably is a better way to achieve what I am trying to
achieve. Let me explain:
I've got a typical Customer/Order/Orderdetail relation.
merge() appeals to me because it does most all the same work I'd
otherwise need to do. I get passed to me an Order object will the
customer
Many thanks.
On Feb 3, 3:44 pm, Michael Bayer mike...@zzzcomputing.com wrote:
Kent wrote:
Any chance SQLAlchemy has a mechanism to switch to or from sysdate vs.
current_date based on the database dialect (and maybe use_ansi)?
It would be really nice if I could program in sqla
For performance reasons, I'd like eagerloading to do inner joins where
possible. I found ticket 1544 http://www.sqlalchemy.org/trac/ticket/1544
addresses exactly this concern, and I've patched the option for
innerjoin=True.
This works, thank you.
I wanted to point out, however, that the orm
not complaining, as I'm very grateful to have found the option
at all. It was just a suggestion.
On Feb 1, 12:22 pm, Michael Bayer mike...@zzzcomputing.com wrote:
Kent wrote:
For performance reasons, I'd like eagerloading to do inner joins where
possible. I found ticket 1544http
While its certainly possible I've done something that isn't designed
for, I am getting inequivalent SQL statements when I flip to
use_ansi=False (unfortunately, I need to support oracle 8i).
I may try duplicating the problem with a more simple query so I can
post the tables mappers here.
This
Wow.
I am very impressed. The patch seems to have fixed this... I'll
inspect it closer later to make sure it all looks correct.
That was very fast. Thanks for taking the time even on a Saturday for
this.
I'm amazed at how fast you responded and fixed that.
Thanks,
Kent
On Jan 30, 2:03 pm
The limit() function behaves in a way that is possibly unexpected:
If you ask sqlalchemy to query limit(3) where a join is involved,
for example, and 2 of the top-3 are actually the same primary key,
sqlalchemy gets the 3 results, throws out the duplicate and your query
size ends up as 2. This
in Oracle -- perhaps for good reason, since it destroys
the order by!)
This case was somewhat contrived and may never present as a live
problem anyway. Thank you for your informative input and speedy
response.
- Kent
On Jan 21, 12:00 pm, Michael Bayer mike...@zzzcomputing.com wrote:
Kent wrote
Given an InstrumentedAttribute object, how can you determine which
data type (int, str, datetime, etc) that the attribute expects to
house?
Thanks in advance if anyone can answer this.
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this
Thank you.
On Jan 18, 9:41 am, Michael Bayer mike...@zzzcomputing.com wrote:
On Jan 18, 2010, at 7:33 AM, Kent wrote:
Given an InstrumentedAttribute object, how can you determine which
data type (int, str, datetime, etc) that the attribute expects to
house?
Thanks in advance if anyone
you need to flip around where you put the delete-orphan rule - see my
previous email on the subject.
In other words:
order_mapper = mapper(Order, order_table, properties=dict
(orderdetails=relation(OrderDetail,
cascade='all,delete-orphan', single_parent=True,
Suppose you have a simple child-parent relationship defined as such:
parent_mapper = mapper(Parent, parent_table,
properties=dict(children=relation(Child)))
I would like to use introspection on the Parent obj to dynamically
determine that its children property is a collection of
,
cascade='merge',
backref='orderdetails')))
metadata.create_all(engine)
ord = Order()
ord.id = '55'
ord.customer = 'Kent'
ln1 = OrderDetail()
ln1.line = 1
ln1.product = 'ARMLESSCHAIR'
ln2 = OrderDetail()
ln2.line = 2
ln2.product = 'WHITESECTIONAL
database. Now, I add two line details like
my original post.
ord = Order()
ord.id = '55'
ord.customer = 'Kent'
ln1 = OrderDetail()
ln1.line = 1
ln1.orderid = '55'
ln1.product = 'DESK'
ln2 = OrderDetail()
ln2.line = 2
ln2.orderid = '55'
ln2.product = 'WHITESECTIONAL'
ord.orderdetails
looking through CHANGES I can see mentions of several issues regarding
flushing, merging, and composite primary keys, though none seem quite to
match this particular symptom. in any case 0.5.2 is an old release so I
would ask that you confirm this behavior on 0.5.7.
Third question: I
None is going to update to null. But this is not the same as empty,
i.e. the key isn't present in obj.__dict__ - that will amount to a skip.
When you first create the object, the __dict__ is blank as far as values -
The None only appears there when you first access the scalar attribute.
Gaetan,
Thanks for your response. I'd like to follow up with two questions:
1. I understand what you mean about the current way I'd have to model
this relationship
in Elixir. This would allow me full control over the intermediate
table, which means I could
put my 'priority' field in it.
I have a many-to-many relationship between two entities, call them A
and B. This is easy enough to model in sqlalchemy using Elixir.
However, to complicate things, I need an integer column somewhere
called 'priority'. In the relationship between an A and multiple Bs,
I want the Bs to be ordered
301 - 331 of 331 matches
Mail list logo
