On 3/29/06, Michael Bayer <[EMAIL PROTECTED]> wrote:
are you thinking of this ? histogram_table_mapper = mapper(histogram, histogram_table)
document_table_mapper = mapper(document, document_table, properties={ 'histogram':relation(histogram_table_mapper)
})
I think that's what I wanted.
But is
theres a full assortment of count() functions, both on selectable query
objects and mappers...seems like a little more docs needed -
sql:
mytable.count()
mytable.count(mytable.c.col1==5)
select([func.count(mytable.c.col1)], mytable.c.col1==5)
mappers:
mapper.count(MyObj.c.col1==5
yeah, its committed right now as built in, but its only a handful of lines
of code. if you wanted to bypass it you could call
mapper.select_whereclause() which is what select() calls anyway.
but yah, i think i want to make it optional. i think per-mapper is one
way it might be used; but i think
Is there a good (or a bad--generate a cusor, go through and count each
one, regenerate cursor) way to get an exact or approximate count on the
number of results in a result set?-- ++ Jonathan Hayward, [EMAIL PROTECTED]** To see an award-winning website with stories, essays, artwork,
** games, and a
Michael Bayer wrote:
Ive integrated it with the mapper, which is quite a small change, just
added to select() (when used with a "where" clause, not if you send it a
full Select object) and select_by(). the major thing you lose with this
approach is that you cant call len() on a returned result s
On 3/30/06, Jonathan Hayward http://JonathansCorner.com <
[EMAIL PROTECTED]> wrote:
On 3/29/06, Michael Bayer <
[EMAIL PROTECTED]> wrote:
are you thinking of this ? histogram_table_mapper = mapper(histogram, histogram_table)
document_table_mapper = mapper(document, document_table, properties={ 'h
Ive integrated it with the mapper, which is quite a small change, just
added to select() (when used with a "where" clause, not if you send it a
full Select object) and select_by(). the major thing you lose with this
approach is that you cant call len() on a returned result set. I tried
having __
Michael Bayer wrote:
Jonathan Ellis wrote:
I don't understand the objection -- #3 is the only one that works in the
general case without inefficiency as in #1 or attaching extra metadata to
user tables as in #2. (SimpleORM uses #3 exclusively. :)
its a huge hit on the database to comp
see that everyone ? not so hard :)
Jonas -
this has been high on my list. im attaching this patch to the ticket,
which was not viewable until now since I forgot to press "submit" on it
three days ago. http://www.sqlalchemy.org/trac/attachment/ticket/142
i have also been thinking of having ava
Hi,
As most of you people already know the SQLObject.select method does not
return a list of the selected instances directly, instead a
SelectResults instance is returned. This instance can then be used to
further manipulate the search query.
`SelectResults.filter` can be used to add another "whe
oh, theres an "ilike", right. i definitely dont want to change "like",
since i do not believe in second-guessing what the database wants to do.
but we could through a specific "ilike" function on there...but then,
every database engine has to find a way to comply with that, i.e. oracle
might have
with eagerload/lazyload, you should treat them as the same, meaning, when
you say mapper.select(), the things asked for in the eager loads have
nothing to do with your select. treat the relationships as though they
arent there. if you look at the generated SQL, eagerloading uses aliases
to keep
Yep, the value being compared. In postgres
SELECT YADAYADA WHERE firstname LIKE "%koen%"
Won't return results with firstname=Koen, whereas
SELECT YADAYADA WHERE firstname ILIKE "%koen%"
will.
Postgres is an exeption to for example mysql in that behaviour. Is
there a pretty way to solve this
Groovy, thanks for the quick response Michael.On 3/30/06, Michael Bayer <[EMAIL PROTECTED]> wrote:
should be, establish the corresponding Table objects against theirappropriate enginethen proceed normally. the objectstore should
commit to each DB as appropriate.hasnt been tested, though, and o
should be, establish the corresponding Table objects against their
appropriate enginethen proceed normally. the objectstore should
commit to each DB as appropriate.
hasnt been tested, though, and obviously eager loading is out the window.
also theres some proposed options on Session that ma
you can say user.c.name.like('koen') right now. also LIKE isnt really a
function its more of a SQL operator. what do you mean by case sensitive,
the value being compared ?
Koen Bok wrote:
> The LIKE function in postgres is case sensitive (unlike other sql
> databases). Is there a way to use it,
OK, I dont know if you noticed that I added an option for you called
"always_refresh" that you can add to a mapper, which will do just that.
so, now it should be established that you should have no issue. the rest
of this email is just conjecture. if you dont like my advice on
objectstore.clear
Jonathan Ellis wrote:
> I don't understand the objection -- #3 is the only one that works in the
> general case without inefficiency as in #1 or attaching extra metadata to
> user tables as in #2. (SimpleORM uses #3 exclusively. :)
its a huge hit on the database to compare against all the columns
I don't exactly understand how to search within the relations of a mapper object. It seems that whatever the search string is for a child object, the mapper always returns every object.Example:order_mapper = Order.mapper.options( eagerload('person'), eagerload('orderproducts'), eagerload('orderpr
Is it possible to use a different database for part of an object?
Example:
I have a Policy object. All the data for it lives in DBPolicy. I
want this object to have a 'documents' property. The rows of
documents for the Policy live in a different database, DBDocs.
Possible?
Thanks,
Tim
I need some instructions on how to use the sqlalchemy tests.
If i get some time, i will try to test the new Firebird-connection.
Thanks,
Uwe
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends a
Koen Bok wrote:
> Postgres had the ILIKE function, but is there a way to use it, while
> still keep compatibility with other databases?
>
Oh, sorry. I thought that this was a typo. Never heard of ilike in SQL.
Uwe
> On 30-mrt-2006, at 16:12, Uwe Grauer wrote:
>
>> Koen Bok wrote:
>>> The LIKE f
Postgres had the ILIKE function, but is there a way to use it, while
still keep compatibility with other databases?
On 30-mrt-2006, at 16:12, Uwe Grauer wrote:
Koen Bok wrote:
The LIKE function in postgres is case sensitive (unlike other sql
databases). Is there a way to use it, and keep dat
Koen Bok wrote:
> The LIKE function in postgres is case sensitive (unlike other sql
> databases). Is there a way to use it, and keep database computability
> with other databases? Eg: not use it as a custom function, but in a
> user.c.name.like('koen') kind of way?
>
>
Like should be case sensit
The LIKE function in postgres is case sensitive (unlike other sql
databases). Is there a way to use it, and keep database computability
with other databases? Eg: not use it as a custom function, but in a
user.c.name.like('koen') kind of way?
I just tested what I assumed, and that's not the case. Overlapping
multi-threaded transactions don't raise transactional errors oracle, just the
last to commit wins.
Quoting Florian Boesch <[EMAIL PROTECTED]>:
> afaik oracle does elaborate concurrency checking, as in it stores a log of
> what
> y
For instance there's a content table where each content is represented as a
single row with type, name and title.
Some of the more specific content-types reference other content, as in there's
an intermediate association table and a relation property on the mapper.
On principle title and the asso
27 matches
Mail list logo
