The Helma.org web site page for Server and Applications Properties needs to be updated for the "repuestTimeOutStop" property. The default is 'false' as of revision 1.32 of Transactor.java that was done on Mar 28, 2007. Thanks, Kris
On Aug 1, 2007, at 23:09 , Kris Leite wrote: > The Helma.org web site page for Server and Applications Properties > needs > to be updated for the "repuestTimeOutStop" property. The default is > 'false' as of revision 1.32 of Transactor.java that was done on Mar > 28, > 2007. Thanks Kris, it's fixed. Chris
hi there last week i filed a bug report with a suggestion to modify helma's getOrderedView() method when using additonalTables: http://helma.org/bugs/show_bug.cgi?id=532 i came across this because i am currently trying to find a generic approach towards listing hopobject collections in a flexible way. ie. i'd like to have all items of a collection in a table-like layout, with two-level grouping (e.g. alphabetical and page number) and sortable header fields. imho it's nothing exotic, just what we are used from desktop applications like a mail client where such an item is represented by a message and the collection by all e-mails. actually, it's like a mirror of what's going on in the database table itself. i consider it a very basic and important way of representing data records which is almost ubiquitous when building applications with helma. currently, i don't see a really feasible option to realize such a thing with helma, at least when avoiding subnodeRelation settings or directDB queries. (although both could be a solution, nevertheless.) what do the other worshiped helma users and application developers think: * is there a way to make this happen without defining much too many collections in type.properties? * is subnodeRelation / directDB the way to go? * could it be done easier and the helma-way simply by adding some nifty helma features? i am really curious about your suggestions. ciao,(Continue reading)
hi tobi, tobias.schaefer <at> orf.at schrieb: > i came across this because i am currently trying to find a generic approach towards listing hopobject collections in a flexible way. > > ie. i'd like to have all items of a collection in a table-like layout, with two-level grouping (e.g. alphabetical and page number) and sortable header fields. > > imho it's nothing exotic, just what we are used from desktop applications like a mail client where such an item is represented by a message and the collection by all e-mails. actually, it's like a mirror of what's going on in the database table itself. > > i consider it a very basic and important way of representing data records which is almost ubiquitous when building applications with helma. > > currently, i don't see a really feasible option to realize such a thing with helma, at least when avoiding subnodeRelation settings or directDB queries. (although both could be a solution, nevertheless.) > > what do the other worshiped helma users and application developers think: > > * is there a way to make this happen without defining much too many collections in type.properties? > * is subnodeRelation / directDB the way to go? > * could it be done easier and the helma-way simply by adding some nifty helma features? > I posted some code to this list a while ago, which somehow solved the problem for us: http://helma.org/pipermail/helma-user/2007-May/007032.html It basically transforms a SQL-query into a HopObject-collection. I tried to mimick the behaviour of Helma's collection, but failed to acchieve the smart caching mechanism, that Helma provides. Caching would then (if(Continue reading)
See this wiki brainstorming page <http://dev.helma.org/wiki/Config+in+Code/>. If Type.collection() would work any time, it would solve your problem, I think. Unfortunately, it doesn't work at all [yet] afaik.
I'd very much second this request - its exactly the kind of functionality I keep missng myself when working on helma apps. I guess the real question is: can this be implemented in the current persistance subsystem or is it such a radical change that it needs to be done in a completely reworked persistance layer for something like helma 2? Actually I'd also like to add that it would be great if this could be supported for both the sql *and* xml db's as that would really bring the xml db implementation upto par with the sql, in terms of features if not performance. Maks. > -----Original Message----- > From: helma-user-bounces <at> helma.org > [mailto:helma-user-bounces <at> helma.org] On Behalf Of > tobias.schaefer <at> orf.at > Sent: Monday, 6 August 2007 19:39 > To: helma-user <at> helma.org > Subject: [Helma-user] managing helma collections > > hi there > > last week i filed a bug report with a suggestion to modify > helma's getOrderedView() method when using additonalTables: > http://helma.org/bugs/show_bug.cgi?id=532 > > i came across this because i am currently trying to find a(Continue reading)
Maksim Lin for technical support mailling lists wrote: > can this be implemented in the current persistance subsystem? I am approximately nobody to Helma, but I've mapped out (in my head) a fairly memory-efficient way to do [most of] getOrderedView on arbitrarily large SQL-mapped collections (i.e., have the DB do the ordering but still use Helma's object cache and retrieve the rows as their proper type, etc., as though they had been retrieved directly from their Hop parent). This could be done just in JavaScript with the interfaces we have now, though some minor fiddling with the Java DB stuff instead of helma's DB class would make it more efficient. getOrderedView returns a collection which has these properties (in the logical sense): 1) contains the same set of objects as the _children of the collection (typically a HopObject) that called it--no more nor less 2) its children may be in a different order from that in which they are mapped in the creator object 3) has [almost] all the usual methods of HopObject 4) but you can't extend it, b/c it's actually a Bean (or something) and created in Java code, not JavaScript code 5) stays in sync with its creator collection in that it sees deletes and adds in real time It would be pretty easy to get 1, 2 and 3, improve on 4, and lose 5. 4 is nice in principle, but not all that important for what appears to be the most common use case (get a subset of a sorted list of the children so we can easily display them). First step is (in a new method, because the current method has its place(Continue reading)
Corrections... Joshua Paine wrote: > It would be pretty easy to get 1, 2 and 3, improve on 4, and lose 5. 4 > is nice in principle, That should be "5 is nice in principle..." > Once it gets the _id value for the arg-th child under its sort order, it > calls get(valueOf_idAsString) on its creator and returns the result. Little bit of playing indicates that get() only has two functioning modes per collection (either number-as-string or string work, but not both). So you'd actually do creator.getById(valueOf_id). -Joshua
I didn't get a chance to read Tobi's actual bug report before writing my email and so I realise now I misunderstood the point of his email being about performance/scalibility with sorting large collections (ie. large mailbox) rather then about the functionality of getOrderedView(). And from a scalability point of view, I think it does make sense to order a collection (mapped to an sql db) using sql rather then in-memory sorting since otherwise for very large collections you won't be able to sort collection that don't fit into the memory cache (or have I misunderstood that?).
Hi everyone, Looking through the helma.objectmodel.db package I spotted the Replicator class which looks like it does replication of the object cache between 2 instances of the same app running in separate instances of helma. But trying to find more info, the only documentation I could find was a mention in this bug report: http://helma.org/pipermail/helma-dev/2003-December/000713.html with the final comment suggesting it be better documentedso were any other docs written about this "hidden" feature? thanks, Maks.
RSS Feed1 | |
|---|---|
2 | |
8 | |
1 | |
21 | |
31 | |
13 | |
16 | |
32 | |
27 | |
21 | |
39 | |
23 | |
34 | |
8 | |
16 | |
46 | |
69 | |
24 | |
57 | |
56 | |
56 | |
36 | |
35 | |
26 | |
25 | |
47 | |
25 | |
77 | |
6 | |
57 | |
69 | |
12 | |
76 | |
39 | |
124 | |
33 | |
53 | |
18 | |
32 | |
71 | |
21 | |
15 | |
47 | |
8 | |
19 | |
22 | |
5 | |
6 | |
12 | |
12 | |
28 | |
7 | |
2 | |
27 | |
39 | |
52 | |
33 | |
25 | |
45 | |
69 | |
16 | |
24 | |
58 | |
34 | |
90 | |
74 | |
47 | |
79 | |
77 | |
41 | |
51 | |
75 |
