On Fri, Jun 22, 2012 at 05:05:15PM +0400, Oleg Broytman wrote:
>The bug was fixed in SQLObject releases 1.2.3 and 1.3.1.
Ah. Thanks. And now at last I figured out how to upgrade :-)
--
:-- Hans Georg
--
Live Secur
On Fri, Jun 22, 2012 at 01:50:26PM +0100, Hans Georg Schaathun
wrote:
> Hi again,
>
> On Thu, Jun 21, 2012 at 10:15:03AM +0200, Petr Jake?? wrote:
> > Hi,
> > I am not sure if following is what are you looking for, but in my case, I
> > have a view defined manually on the SQL server side.
> > in
Hi again,
On Thu, Jun 21, 2012 at 10:15:03AM +0200, Petr Jakeš wrote:
> Hi,
> I am not sure if following is what are you looking for, but in my case, I
> have a view defined manually on the SQL server side.
> in the SQLObject I am working with the VIEW like it with an ordinary table,
> see my code
On Fri, Jun 22, 2012 at 03:26:42PM +0400, Oleg Broytman wrote:
>Yes. And to distinguish "1:11" and "11:1" - without a delimiter you
> get two different rows with the same id; with pure integer id's of a
> limited range that can be fixed in a different way:
>
>SELECT t1.id*10 + t2.i
On Fri, Jun 22, 2012 at 01:16:02PM +0200, Petr Jake?? wrote:
> >SELECT CAST(t1.id as TEXT) + ':' + CAST(t2.id as TEXT) AS id, ...
> >
> >
> Just wondering what is delimiter helpful for? Just to recognize t1.id and
> t2.id later on?
Yes. And to distinguish "1:11" and "11:1" - without a deli
>SELECT CAST(t1.id as TEXT) + ':' + CAST(t2.id as TEXT) AS id, ...
>
>
Just wondering what is delimiter helpful for? Just to recognize t1.id and
t2.id later on?
Petr
--
Live Security Virtual Conference
Exclusive live e
On Fri, Jun 22, 2012 at 07:34:50AM +0100, Hans Georg Schaathun
wrote:
> On Fri, Jun 22, 2012 at 12:56:05AM +0400, Oleg Broytman wrote:
> >I think there have to be a way to generate id's for a complex VIEW
> > by, e.g., combining id's into a string with a delimiter; SQLObject
> > supports stri
On Thu, Jun 21, 2012 at 10:45:40PM +0200, Petr Jakeš wrote:
> Did not think about this (I do not know the ViewSQLObject class). My
> feeling is I do not need more CPU load on the client side (which IMHO
> ViewSQLObject is).
I am not sure that makes a difference. There is no reason why
ViewSQLObje
On Thu, Jun 21, 2012 at 10:45:40PM +0200, Petr Jake?? wrote:
> I am sure Oleg is reading this and
> gives his comments about the issue.
I think there have to be a way to generate id's for a complex VIEW
by, e.g., combining id's into a string with a delimiter; SQLObject
supports string id. Or c
>
> Obviously, if you only have many-to-one relationship (from left to
> right) you can just use the ID of the left hand table. AFAICS that
> must be your case. My problem is that the join involves two many-to-many
> relationships, so I cannot even use the ID's of the relation table.
>
Hmmm... a
On Thu, Jun 21, 2012 at 08:44:18PM +0200, Petr Jakeš wrote:
> Acording the unique m.id: generally it depends about the construction of
> your select. In my example I am pretty sure it returns unique IDs only.
Obviously, if you only have many-to-one relationship (from left to
right) you can just us
> Well. I did not understand the syntax of your view definition.
> In particular, I do not understand the meaning of «hash». Is
> it a keyword in some dialect of SQL? (I don't find it in postgresql.)
> If it is a table name, what is then m/m1? Second question, what makes
> sure that the id, pr
On Thu, Jun 21, 2012 at 06:38:09PM +0200, Petr Jakeš wrote:
> Hmmm Views, IMHO, are just SELECTS transformed to views. It means not
> special SQL digging is necessary.
Well. I did not understand the syntax of your view definition.
In particular, I do not understand the meaning of «hash». Is
On Thu, Jun 21, 2012 at 06:38:09PM +0200, Petr Jake?? wrote:
> Hmmm Views, IMHO, are just SELECTS transformed to views. It means not
> special SQL digging is necessary.
They are very convenient for factoring out common SELECTs for stored
procedures, e.g., and for granting access to some pa
I suppose I was looking for the ViewSQLObject class as a way to achieve
> the same thing with a lesser need to learn more SQL ...
>
> Anyway, thanks for the code example. I reckon I can figure out how
> it works by reading up on hash joins.
>
>
Hmmm Views, IMHO, are just SELECTS transformed t
On Thu, Jun 21, 2012 at 10:15:03AM +0200, Petr Jakeš wrote:
> Hi,
> I am not sure if following is what are you looking for, but in my case, I
> have a view defined manually on the SQL server side.
I suppose I was looking for the ViewSQLObject class as a way to achieve
the same thing with a lesser
Hi,
I am not sure if following is what are you looking for, but in my case, I
have a view defined manually on the SQL server side.
in the SQLObject I am working with the VIEW like it with an ordinary table,
see my code below:
=== SQLObject part ===
class HashView(SQLObject):
Hi,
I decided to try the ViewSQLObject class in an attempt to speed up my
system by letting the server do some of the table joins in single queries,
instead of joining in python on the client side.
But I get stuck at the id. I assume that ViewSQLObject objects
need an immutable and unique ID (i
18 matches
Mail list logo
