I am trying to retrofit an existing application to use SQLalchemy; it uses its own database which is painfully slow.
I am presently trying to get lists working correctly; objects have
lists of strings/other objects, and so I am trying to make a separate
table for each list item, so that a row in
I originally would've stayed on a stable version, except, it was bugged mainly
for oracle usage, so I *had* to move to the newer versions.
And don't you darn shove the you lousy slack up my arse. Do you have *any*
idea how hard it is to isolate a specific mal-behaving combination in a huge
model,
With 1:m or n:m relationships served up by a relation property on a mapper, is
there any way not selecting everything that relates, but with a limit/offset.
For example. mytable.somerelation[offset:offset+x].
I guess not, I've seen this beeing mentioned here I think. So what's right now
my best
Florian,The bottom line is, participating in a project doesn't give you the right to bitch at the lead who is doing far more work than you. (Especially when the bugs you're complaining about are the direct results of features you requested yourself!) The sooner you figure that out, the more
On 28 Mar 2006 at 13:15, Rick Morrison wrote:
That would be me. It's currently misbehaving on binary / unicode data
with pymssql, but I was considering posting it anyway for experimental
work, as I'm getting tired of resolving conflicts on each svn up.
Great, will this go into trunk?
When
the simple answer is yes, just handwire it.
there is a desire for a generator to be stuck on relations the way
SQLObject does it, so that x.y[3:5] would set up LIMIT and OFFSET
appropriate to the criterion. this would only work with lazy loading. im
not really sure if that paricular interface
seems like the maintainer is MIAid have to look up his email address
in my folders
You should feel free to fix it up ! whoever can contribute, that would be
great.
Brad Clements wrote:
On 26 Mar 2006 at 16:52, Michael Bayer wrote:
firebird doesnt work at all right now AFAIK...if it
On 28 Mar 2006 at 17:11, Michael Bayer wrote:
seems like the maintainer is MIAid have to look up his email
address in my folders
You're talking about the maintainer of the Firebird module?
You should feel free to fix it up ! whoever can contribute, that
would be great.
Are
Brad Clements wrote:
On 28 Mar 2006 at 17:11, Michael Bayer wrote:
seems like the maintainer is MIAid have to look up his email
address in my folders
You're talking about the maintainer of the Firebird module?
yes. his name is James Ralston.
You should feel free to fix it up
Wow it's... just... beautifull... snif (minus the typo)One other question. You remember my problem from two days ago? Because the relations of a mapper object are not standard lists, pyobjc wouldn't bind them. It turns out, that when I bind the NSArrayController to relation.data it works
Hmm I was too soon. This still does not work. No errors, the the db just does not get updated...This works perfect, but no threads... def commit_(self): objectstore.commit()On 29-mrt-2006, at 1:24, Jonathan Ellis wrote:Since you don't say what your error is, I will just show how to make your code
I'm pretty sure that committing in a separate thread will commit objects modified in that thread only, since SA's unit-of-work is thread-local.Perhaps we can suggest an alternative if you give more info on what you're trying to accomplish.
On 3/28/06, Koen Bok [EMAIL PROTECTED] wrote:
Hmm I was
Okay, I have a Cocoa model-view-controller application. The controller is very basic, it has a fetchall function to get all the data and to put it in a list. In the interface I can change some stuff. By pressing a button bound to the commit function I'd like to start a thread which calls an
the default behavior is that changes to objects are logged in a session
that is local to the current thread.
this can be modified in two basic ways: using per-object sessions, or
changing the algorithm used to get the current session.
these are now documented ! here:
Michael Bayer wrote:
Optimistic
concurrency checking simply means when you UPDATE or DELETE rows, you
insure that the returned row count matches correctly. This is how
Hibernate does it, and its how SQLAlchemy does it.
I don't think you've got that quite right. Checking the affected row
So since I don't know which objects might be updated, I clear them all?
Quoting Michael Bayer [EMAIL PROTECTED]:
Florian Boesch wrote:
Now why would I get so incredibly pissed at this caching issue. Well, it's
because Michael to my understanding basically told me in one go that I'm a
16 matches
Mail list logo
