Views look a bit flaky. Consider (in a fresh session):q)\d .testq)t:( c1:abc; c2:1 2 3)q)v::select c1 from t where c2\>2q)v'vq)\v,tq)\v .symbol$()q)views .testsymbol$()q)views .,vSo it looks like a view was created in the root workspaceand not in the current one, which is a bit confusing. Nextq).test.v::select c1 from t where c2\>2q)vc1--cq)\vs#tvq)views .testsymbol$()q)t,:(d;4)q)vc1--cq)type v98hThus the form .test.v:: did not create a view in the currentworkspace either but an ordinary table. How can I createa view in the current workspace?It gets better:q)\d .q)v'tq)vq)view v"select c1 from t where c2>2"The first result I can understand: it just means I shouldhave used .test.t in the view definition (which probably meansyou can’t create views inside functions) but the second??v still still has its original definiton but somehow it changedafter the first attempt to evaluate it? This is a mess.Also, what is the type of a view? Apparently 0h but thefunction references gives 0h as the type of heterogeneous lists.It seems odd that views wouldn’t have their own type and evenodder that they should be thought of as lists.
Date: Tue, 10 Mar 2009 22:11:42 +0000Message-ID: <1855e77f0903101511s72e251a4l479f6c1b3a056502@mail.gmail.com>Subject: Re: [personal kdb+] Question about viewsFrom: Attila Vrabecz <attila.vrabecz>To: personal-kdbplus@googlegroups.comviews are indeed a bit messythey only work in root namespaceonly work with globalsand a view can be only one linealso whitespace mattersb:1a::1+b /it is a viewa ::1+b /it is notsome internals views can be inspected the following wayq)viewa"1+b"q). a1+bq)value. a2 /value, :: if unitialized yet(+;1;b) /parse tree of the dependency expression,b /dependent variables"1+b" /text definition AttilaOn Tue, Mar 10, 2009 at 8:41 PM, annakh7 <annakh7> wrote:>> Views look a bit flaky. Consider (in a fresh session):>> q)\d .test> q)t:([] c1:abc; c2:1 2 3)> q)v::select c1 from t where c2>2> q)v> 'v> q)\v> ,t> q)\v .> symbol$()> q)views .test> symbol$()> q)views .> ,v>> So it looks like a view was created in the root workspace> and not in the current one, which is a bit confusing. Next>> q).test.v::select c1 from t where c2>2> q)v> c1> –> c> q)\v> s#tv> q)views .test> symbol$()> q)t,:(d;4)> q)v> c1> –> c> q)type v> 98h>> Thus the form .test.v:: did not create a view in the current> workspace either but an ordinary table. How can I create> a view in the current workspace?>> It gets better:>> q)\d .> q)v> 't> q)v> q)view `v> “select c1 from t where c2>2”>> The first result I can understand: it just means I should> have used .test.t in the view definition (which probably means> you can’t create views inside functions) but the second??> v still still has its original definiton but somehow it changed> after the first attempt to evaluate it? This is a mess.>> Also, what is the type of a view? Apparently 0h but the> function references gives 0h as the type of heterogeneous lists.> It seems odd that views wouldn’t have their own type and even> odder that they should be thought of as lists.>> >></attila.vrabecz>
Thanks again. With so many restrictions, what are views good for,really? What is the use scenario?
X-Mailer: Apple Mail (2.930.3)On 11.03.2009, at 01:22, annakh7 wrote:>> Thanks again. With so many restrictions, what are views good for,> really? What is the use scenario?when working with large tables that are changing frequently it’s very useful to have a way to have complex/expensive results only materialised on demand
But I meant, isn’t the fact that they must live in the root workspaceunpractical?It is good practice to keep a particular project in its own workspace,I think. Butany view defined on one of the tables of this project will liveunder . and thus willbe (i) separated from the rest of the project and (ii) comingled withthe views fromother projects. I can’t see under these conditions why you would wantto use them.
X-Keywords: interestingMime-Version: 1.0 (Apple Message framework v930.3)Date: Thu, 12 Mar 2009 10:15:23 +0100X-Mailer: Apple Mail (2.930.3)On 11.03.2009, at 18:55, annakh7 wrote:> But I meant, isn’t the fact that they must live in the root > workspace unpractical?> It is good practice to keep a particular project in its own > workspace, I think. But> any view defined on one of the tables of this project will live > under . and thus will> be (i) separated from the rest of the project and (ii) comingled > with the views fromnormal q practice is to keep tables and views in the default namespace and code with related small variables in appropriate namespaces
OK. That assumes that each project has its own Kdb instance, though.