Thanks in advance for the discussion, hope I can continue without you
feeling I'm taking too much of your time...
You said
If you are using merge(), and you're trying to use it to figure out
what's changed, that implies that you are starting with a business
object containing the old data and
I think I've got a strategy that will work and doesn't mean hacking
merge()...
Thanks for your input, if you have inspiration, I'll still gladly hear
it.
On Apr 30, 8:18 am, Kent Bower k...@retailarchitects.com wrote:
Thanks in advance for the discussion, hope I can continue without you
Kent Bower wrote:
Could I look it up in a separate session and then merge it into my main
session? Then, after that, merge the transient objects into my main
session? Would that get me closer? Ideally, I wouldn't want it to need
2 trips to the database.
there's this implication here that
On 4/30/2010 11:17 AM, Michael Bayer wrote:
Kent Bower wrote:
Could I look it up in a separate session and then merge it into my main
session? Then, after that, merge the transient objects into my main
session? Would that get me closer? Ideally, I wouldn't want it to need
2 trips to
That sounds like it could be very useful for me, thank you for
pointing me there. That could solve one of the two issues I'm facing
that I listed... what about the other?
On Apr 29, 11:02 am, Michael Bayer mike...@zzzcomputing.com wrote:
Kent wrote:
Before saving objects to the database, we
if you have a method like 'calculate_total_volume()', that is a business
method. you should not be relying upon the internals of the ORM to figure
that out for you, and you should have two distinct fields on your object
to represent the two values you need to make that calculation.
Kent wrote:
There might be a communication problem, which an example could help
clarify.
I'm constrained by a legacy database that I have no control over
changing. When an order is changed, I need to calculate the change in
volume (or points) so I can update a table that records this
information.
Here is
Kent wrote:
There might be a communication problem, which an example could help
clarify.
I'm constrained by a legacy database that I have no control over
changing. When an order is changed, I need to calculate the change in
volume (or points) so I can update a table that records this
Michael Bayer wrote:
Kent wrote:
There might be a communication problem, which an example could help
clarify.
I'm constrained by a legacy database that I have no control over
changing. When an order is changed, I need to calculate the change in
volume (or points) so I can update a table
I'm exactly trying to avoid adding esoteric hacks - (why I posted in
the first place), so thanks for the information. I'll look into the
examples you've provided; I'm hopeful that the versioned objects have
in-tact relations (such that I could say old_object.orderdetails
and get that
It is helpful to know what SQLA was designed for.
Also, you may be interested to know of our project as we are apparently
stretching SQLA's use case/design. We are implementing a RESTful web
app (using TurboGears) on an already existent legacy database. Since
our webservice calls (and
Kent Bower wrote:
It is helpful to know what SQLA was designed for.
Also, you may be interested to know of our project as we are apparently
stretching SQLA's use case/design. We are implementing a RESTful web
app (using TurboGears) on an already existent legacy database. Since
our
12 matches
Mail list logo
