Where does one find the definitive documentation on using CacheSQLStorage? I can't seem to find any good documentation on this feature anywhere.
Thanks, Justin Eatinger "Peter Cooper" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Richard > > You have hit on the real implantation issues in Cache that needs to be > dsigned for - ISC may make it more efficient between versions but you > will still hit a barrier somwhere > this is esp true of drawing objects where there are potentially a very > large number of items > > <snip /> > > > >ISC support have confirmed this as a problem and suggested we work > >around it by using parent/child relationships instead. Unfortunately the > >performance of these (as of 5.0.7) is dismal. > there is a major performance issues when you access child objects > (more than ~1000) like this > > set o=##class(Diagram).%OpenId(DiagramID) > for i=1:1:o.Points.Count() > { > render point(pX,pY) > } > > it's due to poor memory management in having to open all the child > objects > > if you do it like this > &sql(declare c1 cursor for > select pX,pY > into :xX,:xY > from Diagram.Points > where rParent=:DiagramID > order by %ID > ) > > &sql(open c1) > &sql(fetch c1) > while SQLCODE=0 > { > render point(xX,xY) > &sql(fetch c1) > } > &sql(close c1) > > gives much better scaleability > > >As a further refinement, > >they have now suggested simply writing the data directly into the > >global representing the class data. > is it writing or reading that is the main issue > > > In principle, this is OK (as we > >don't need to expose the values via SQL, > if you maintain the Cache structure then you can still do SQL > > >and we have specific accessor > >methods for all our properties anyway), and the performance is terrific. > > > >However, there is almost no information that I can find on the do's and > >don'ts of mixing home grown global nodes into the stuff generated by > >Studio. Is anyone aware of any "howto" documentation for people who want > >to start tweaking storage definitions? > you are not really tweaking the definitions - I guess you are taking > the CacheStorage definitions and accessing the *data* directly > > The main potential problem with this is that if you do something that > changes the storage definition (eg deleting the storage and > recompiling) the data locations can change radically > > >Also, if I did want to > >subsequently expose this sort of data via SQL, how would I go about > >building the mappings? > > Why not go to CacheSQLStorage - this is primarily intended for mapping > legacy globals but you can use it to good effect here > The difference is that the compiler does nothing to automatically > generate the definitions you have to do it all yourself - hence you > have absolute control over the data location > and you maintain SQL/ODBC access with no hacks > > ==== > Also have you really got a single drawing object with 2,000 points?? > > I have done stuff where the final diagram has 5,000 points but this is > made up of lots of different drawing objects (each object can be a > compound object that contains other drawing objects) - no one object > has more than a few 10's (<100) points !! > > > > > > >All suggestions welcome! > > > >Richard > > >
