As Oleg notes, your default argument call to byName is evaluated at class
creation time ie, before you've created the Sales Department record. In the same
way, if you had:
when = DateTimeCol(default=now())
the default would always be the value returned by now() at the time the class is
imported
First off, let me say I feel RelatedJoin and MultipleJoin should be deprecated
to be renamed RawRelatedJoin/RawMultipleJoin, there are two better alternatives
available since at least 0.8:
* SQLRelatedJoin and SQLMultipleJoin
* ManyToMany and OneToMany
Yes, the docs need a massive overhaul on
Oleg Broytmann phd.pp.ru> writes:
>Thank you very much! Now if I only can formulate a short description for
> it. ".j attribute on SO classes" is not very informative.
>"New magic attribute 'j' similar to 'q' that automagically does join
> with the other table in FK/MultipleJoin"?
Yeah, t
Oleg Broytmann phd.pp.ru> writes:
>Looks good, and 'j' is pretty good "magic" name, IMHO. Will you work on
> a patch?
>
r3342 in trunk. New subclass of sqlbuilder.SQLObjectTable named
SQLObjectTableWithJoins that has the .joinName/.foreignKeyName (and falls back
to SQLObjectTable attrs as w
Oleg Broytmann phd.pp.ru> writes:
>
> On Mon, Mar 10, 2008 at 08:57:35AM -0700, Daniel Fetchinson wrote:
> > On Mon, Mar 10, 2008 at 3:12 AM, Oleg Broytmann phd.pp.ru> wrote:
> > > On Sun, Mar 09, 2008 at 08:52:28PM -0700, Daniel Fetchinson wrote:
> > > > class zoo( SQLObject ):
> > > > cag
> > No, RelatedJoin doesn't expose an API to do a join with the
> > intermediate
> > table.
>
> Ok, that what I thought. I'll do the join myself then.
>
> Thanks
> -fred-
However, you're certainly free to have both a RelatedJoin and a MultipleJoin,
ie:
class Mbox(SQLObject):
...
msg_t
As with the general questions that come up around .select() and joins, the
underlying issue is the expectation that "instances of a SQLObject-derived class
are returned". So in your work here, the main bit is creating a fake class that
is "enough" like a SQLObject.
Also in trunk (views.py) is an a
It's missing something, presumably you want to return the traversed FKs (or
their .q expression) in addition to the classes found in the search (building
the expressions as X.id == Y.id will not get the results intended, you want
X.fkToYID == Y.id). I'd probably let .q handle more of the work in
Bu
Alright, after professing my preference for post-Signal over post_funcs in the
previously mentioned cases, I have to admit that for RowDestroySignal I need
post_funcs behavior. For consistency then I'll propose the following changes:
RowCreate, RowUpdate, and RowDestroy signals should all take a p
Not RowCreateSignal (called before insert, allowing modification of kwargs) but
RowCreatedSignal (called after insert).
It is currently defined as (kwargs, post_funcs), but never calls post_funcs and
would make a lot more sense to send the newly created instance. The docs suggest
there may also be
Nick Murdoch locayta.com> writes:
> I'm coming across difficulty while trying to find out which tags a user
> has used for a particular page. At the moment I've had to resort to the
> following code, but I'm sure this should be possible as a pure select()
> statement or similar.
>
> # page an
Oleg Broytmann phd.pp.ru> writes:
> > #3 is also intended to fix the "TypeError:unhashable instance using
> > sqlbuilder.Table" bug (SF#1642143) that was recently added
>
>Just yesterday I applied the patch
>
http://sourceforge.net/tracker/index.php?func=detail&aid=1673013&group_id=74338&atid
After some time away, a chance to cleanup my changes to SelectResults and
SQLBuilder and submit them to all of you. Those changes fall into the following
areas:
1. SelectResults use SQLBuilder Select queries.
2. SQLBuilder Select supports rest of SelectResults options (reversed, distinct,
etc)
3.
Johan Dahlin async.com.br> writes:
> I wrote something similar a couple of weeks ago, I didn't submit it to
> the mailing list because it was not in my opinion clean enough to be
> submitted upstream.
Indeed, I make no specific claims that my code is ready to be released into the
wild yet. :) T
Ok, want to let you all in on something magical that made my weekend. This is
an extension to my earlier thread on using SQLBuilder more consistently in
SQLObject.
On Saturday I expanded and refactored slightly on my last efforts, including
cleaning up the reaching into DBConnection._SO_selectOne/
Oleg Broytmann phd.pp.ru> writes:
>
> Hello!
>
> On Wed, Feb 14, 2007 at 10:11:34PM +, Luke Opperman wrote:
> > Ok, put a slightly updated version on SF Patch #1653898
>
>Wow! Though it is rather large it is a clever patch from a developer
> with good u
I meant SF #1660094, clearly. :)
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and ea
Oleg Broytmann phd.pp.ru> writes:
>IWB interesting to see the code.
Ok, put a slightly updated version on SF Patch #1653898
The description there is pretty complete, the relevant changes for the
Alias/Join part are below, but note the big caveat from the SF description:
the db argument to
Ok, two things today:
1. Preview implementation of just the "use sqlbuilder.Select for queryForSelect"
part is in trac #291, but trac is now down. I've attached the patch (against svn
r2158) to this message too.
2. Found a fun problem with sqlbuilder.SQLJoin. Since Alias's don't have a
__sqlrepr_
Oleg Broytmann phd.pp.ru> writes:
>That would be hard to implement, I am afraid. Select() is (must be) much
> more generic, supporting groupBy and many other features of SQL SELECT...
Correct that Select by itself must be more generic, I wouldn't be opening up
direct select() kw access to gr
Oleg Broytmann phd.pp.ru> writes:
>
>I have a desire to do that, but not much time...
Not swimming in time here, but this is looking like a promising approach to my
current critical work.
>Do you mean SelectResults.ops["orderBy"], ops["join"], ops["start"],
> ops["end"], etc.?
Indeed,
Bringing this subject up again, had someone done some work on unifying these, in
particular having SelectResults provide the fully constructed query to the DB
layer in the form of a sqlbuilder.Select?
My current desire is to be able to retrieve / replace the full query of a
SelectResults, and to b
Ben Sizer gmail.com> writes:
> So, how would I implement queries like the following?
>
> # All User 1's skills where competence > 3
> SELECT * from User INNER JOIN Skill USING (user_id) INNER JOIN
> Skilltype USING (stype_id) WHERE user_id = 1 AND Skilltype.competence
> > 3
Well, note that SQLO
> One thing I'm wondering: is there some source of documentation that I'm
> missing? The filter() method doesn't seem to be described anywhere in the
> official docs at http://www.sqlobject.org/SQLObject.html
>
> Dan
Indeed, documentation on SelectResults is pretty sparse -
http://www.sqlobject.o
Depending on what you're actually trying to do, there's a few options. One, if
you just want filtered results (like user.activeRoles), that's a simple filter
on user.roles. If you really want to loop over all roles and get information
from the intermediate table, you probably want both a SQLRelated
Completely untested, but what about:
class A(SQLObject):
class sqlmeta:
idName = 'Ident'
class A1(A):
class sqlmeta(A.sqlmeta):
table = 'TableA1'
- Luke
Quoting Robert <[EMAIL PROTECTED]>:
> Hello,
>
> I have encountered a situation where I'd like to define a common
Django is handling two pieces of the puzzle, only one of which is SQLObject a
replacement for: database model, and admin UI. In Django presumably the
"human-readable" descriptions are never in the database, so it functionally
behaves like the EnumCol at the db level.
Options for you seem to be a)
Yep, docs could be slightly clearer that the - works with the string and the
reversed works in both cases. I'd also probably mention sqlbuilder.DESC, since
it's the parallel to -.
'''
With a string, you can use "-colname" to specify descending order, with a
SQLBuilder (.q) field you can use DESC(T
Quoting Sean McBride <[EMAIL PROTECTED]>:
> Number 2 sounds decent to me too, but I can see a potential problem: A
> class that had a DerivedJoinSum on it (or another one of the derived
> accumulators) would ALWAYS have to do the more complicated select
> statement behind the scenes in order to ge
Quoting Rick Flosi <[EMAIL PROTECTED]>:
> I think it might not exist b/c it isn't very SQLObjecty.
> You'd be returning an object with a new field in it, SUM(), which isn't
> part of the SQLObject and probably a subset of the SQLObject fields as
> well. This isn't very OO which is what I think SQL
That restriction was based on the lack of synchronization of instance caches,
applied in r1581 & a further fix in r1683. As I recall, those are both after
0.7.
However, if you are *exclusively* using transactions (don't have a main plain
connection whose instance cache matters), you can still use
> Then, a query for each getattr :
> 1/QueryOne: SELECT thastate_id FROM validdata WHERE id = 78
> 1/QueryR : SELECT thastate_id FROM validdata WHERE id = 78
> 1/COMMIT : auto
> 1/QueryOne: SELECT tsastate_id FROM validdata WHERE id = 78
> 1/QueryR : SELECT tsastate_id FROM validdata W
No, but there is the IN operator:
Table.select(IN(Table.q.value, possibleValues))
- Luke
Quoting Jonathon Anderson <[EMAIL PROTECTED]>:
>
> Is is possible to use the 'in' keyword with SQLBuilder/SQLObject? For
> example:
>
> possibleValues = [1, 2, 3]
> Table.select(Table.q.value in possibleVal
http://sourceforge.net/tracker/index.php?func=detail&aid=1524615&group_id=74338&atid=540674
With close=True, Transaction.commit() calls
_makeObsolete before synchronizing the main connection
cache - this resets Transaction._deletedCache, so
objects deleted in the transaction are never expired.
In
Apologies, didn't see that you mentioned the SQLObject version.
Anyways, tested
with r1675 and same successful result as below.
Quoting Luke Opperman <[EMAIL PROTECTED]>:
> Going to need to know what that unhelpful exception message was, what version
> of SQLObject, database
Going to need to know what that unhelpful exception message was, what version
of SQLObject, database, etc. Threw your code into a test file, using svn
SQLObject, sqlite and postgres, and it works fine:
[EMAIL PROTECTED]:~/code $ python2.4 -i test1.py
>>> me
>>> me.memberJID
>>>
- Luke
Quoting
Forgot to copy the list before, gist was use SQL*Join instead, so that it uses
a SelectResults instance. That's also the answer here: you can then use
.count, .filter, .sum, etc on the join property.
j.transactions.count()
Quoting Michael Gauckler <[EMAIL PROTECTED]>:
> Hi,
>
> thank your for t
I don't recall whether getstate/setstate are necessary - i think so, just for
the protocol. the key is overriding new/getnewargs. i also don't recall how
generally applicable this is, regarding different connection schemes etc.
## Pickle protocol hacks
def __new__(cls, *args, **kw):
sqlbuilder.Select looks like it's supposed to handle lists or tuples (although
yes, by type-checking). And then in __sqlrepr__ it appears it is using
things = self.items[:]
Presumably this is intended a) to make a copy so that appending to things
doesn't update self.items and b) to cast to a lis
You could use a SQLRelatedJoin, and then do:
coll.members.count()
- Luke
Quoting Oleg Broytmann <[EMAIL PROTECTED]>:
On Thu, Apr 20, 2006 at 03:54:18PM +0300, Max Ischenko wrote:
Is there a way to use a COUNT(*) query in context like these?
There is no currently.
Oleg.
--
Oleg Bro
Patch [ 1464379 ] Alternate fix for Bug 1458595 (with test)
http://sourceforge.net/tracker/index.php?func=detail&aid=1464379&group_id=74338&atid=540674
- Luke
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that
Bug in SQLMultipleJoin and SQLRelatedJoin, the non-SQL versions check
inst.sqlmeta._perConnection and load the joined objects using
inst._connection, but the SQL versions never specify a connection.
I won't have time to write a test for this patch till at least tomorrow or
early next week, but fig
In SQLObject, a class is a table, an instance is a row of that table. You
appear to be confusing object initialization with class initialization -
things in sqlmeta apply to how the class is defined, basically happens at
import time. __init__ is not called until you try to create an instance of th
Quoting Justin Azoff <[EMAIL PROTECTED]>:
The problem I was seeing was similar to this, but not the same. The
stale values were not coming from sqlobject caching at all, but from the
MVCC in postgresql...
Using transactions for all reads will get around this problem, but the
root cause is th
Quoting John Speno <[EMAIL PROTECTED]>:
As all of our sqlobjects have 'cacheValues = False' set. Obviously,
this didn't help the transaction problem before the fix, bu should
the fix introduced in r1581 to cache.py fix our inconsistency problems?
The fix in r1581 was originally written in ord
45 matches
Mail list logo
