Joshua Paine | 1 May 18:35

DB Transactions and Insert order

I'm building my first Helma app using an RDBMS (H2, in this case)--I've
used the XML Object DB before.

I've noticed two things:

1) Helma does not appear to use the database's transactions. I found a
thread about this from 2001 with Hannes offering to implement it and one
person voting it up (as a default-off datasource-selectable
feature)--can I add my upvote? Except that I think here in 2008 most
people not using MySQL know what transactions are and pretty much expect
they'll be used, so maybe it should be default on in a future version?
Even MySQL supports transactions if you use InnoDB tables. I've searched
the source code as best I can, and it doesn't look like this has
actually been added yet. Please let me know if I missed something. The
two advantages of implementing this would be (1) that if you get a DB
error in the middle of a commit, the DB is not left in an inconsistent
state, and (2) often much better performance in the case of bulk object
creation.

2) I designed my DB with some foreign key constraints not expecting
Helma to do anything particular about them but expecting that there
would not be any conflict. However, as I'm bulk importing hierarchical
data, I'm getting foreign key constraint violations. I always create the
parents before their children, so as best as I can tell during commit()
Helma doesn't necessarily insert nodes in the order they were created.
Perusing objectmodel/db/Transactor.java, I see that "dirty" nodes are
kept track of with a HashMap, which of course doesn't guarantee any
particular order when you convert it to an array. Am I reading it right?
Could this be fixed? If I'm reading right, it seems that just using a
LinkedHashMap instead of a HashMap would do the trick.
(Continue reading)

Anton Pirker | 1 May 23:38

Re: Helma vs Broadvision

Hi Ruben!

(Sorry for answering so late)
I once (already a few years ago) was part of a team which implemented a 
big portal website in broadvision One-To-One. (it was omv.com)

I did not do all the really hardcore development with broadvision, but 
made a view modules of the website and also some server-administration

Some things i can remember:

-) Broadvision License and Support was _really_ expensive (Helma is free 
and Helma developers do not cost as much as Broadvision-Consultants)
-) Setup of a Broadvision-System (for development for example) was a 
very complicated procedure and took hours (A simple Helma is up and 
running in a few Minutes)
-) Our Broadvision Portal needed eleven big IBM Servers to run smoothly. 
The _special_ hardware was quite expensive. I don't know about any 
Helma-App this size, but www.twoday.net (which is the biggest german 
speaking blog-site) runs on a few _cheap_ servers with PC architecture.
-) Broadvision Application had quite a lot of complicated config-files 
to configure. If anything was wrong the problem could be on a lot of 
places in the app. Configuration of Helma-Apps is quite easy.
-) Handling load balancing was really good in Broadvision, the also had 
some quite good always online feature. (so when you rebooted some 
servers of the cluster no one every noticed this because the current 
sessions stayed online till they finished, new sessions were prohibited, 
after all session where gone it was rebooted automatically) For 
clustering there is Helma-Swarm. I have not used it myself so i only can 
tell that i have never heard someone who uses it complaining about Helma 
(Continue reading)

Picon

Re: DB Transactions and Insert order


> I've noticed two things:
> 
> 1) Helma does not appear to use the database's transactions. 
> I found a thread about this from 2001 with Hannes offering to 
> implement it and one person voting it up (as a default-off 
> datasource-selectable feature)--can I add my upvote? Except 
> that I think here in 2008 most people not using MySQL know 
> what transactions are and pretty much expect they'll be used, 
> so maybe it should be default on in a future version?
> Even MySQL supports transactions if you use InnoDB tables. 
> I've searched the source code as best I can, and it doesn't 
> look like this has actually been added yet. Please let me 
> know if I missed something. The two advantages of 
> implementing this would be (1) that if you get a DB error in 
> the middle of a commit, the DB is not left in an inconsistent 
> state, and (2) often much better performance in the case of 
> bulk object creation.

Hmm, I wonder if this is just a matter of turning off "auto-commit" on
the JDBC connection?
I would then imagine the commit on the JDBC conn would go around line
418 of Transactor.java since helmas "own" transaction commit happens
there for the benefit of the XML DB. The tricky thing looks to be
figuring out how to get your hands on teh undedrlying JDBC conn object
in that commit() method of the Transactor class...

Though its been a while since I've done any "raw" JDBC coding so maybe
I'm making it sound easier then it iwould be to implement.

(Continue reading)

Anton Pirker | 2 May 11:58

Continuations and error handling!

Hi List!

I am implementing a multi-page form with the new Helma continuations. 
Till now everything works really great.

But now i want to stay on the first page if there was an error in the 
data supplied. But it seems that there is no way to do this. After a 
submit i get always the second page.

Is there a possibility to stay on the first page in the case of an error?

Thanks,
Anton

--

-- 
DI(FH) Anton Pirker, Helma Freelancer
Kris Leite | 2 May 21:56

strictVars not wot working?

It appears that there is a error in the documentation that states the 
rhino.strictvars will activate the Rhino strict variable feature.  It 
appears to me that the parameter is actually "strictVars".

Also, has anybody confirmed that it works in Helma?  I tried it and made 
sure the proper parameter was set but didn't get a warning message on a 
simple test.  I did also have rhino.debug=true also if that was needed.

Thanks,
Kris
Kris Leite | 5 May 03:49

markAsClean

I was using onInit function call to create some new fields in a 
HopObject.  When doing that, Helma will mark the node as dirty.  I 
needed a method of reseting the node as clean so that unnecessary 
updates to the data base was not done.  So I created a new HopObject 
function call 'markAsClean' that can be called to remove the node from 
the dirty list.

Other people may find this a useful feature also so I would like to 
suggest that it be considered for implementation into Helma.

Thanks,
Kris

PS - I am aware of the cache feature to allow storing fields into the 
HopObject for temporary storage.  In my case, it was much better to 
create HopObject fields with default values.  If the user changed the 
default values, then they are stored.  If nothing was entered, then the 
default values are not stored reducing storage overhead.
Joshua Paine | 5 May 04:16

Re: markAsClean

On Sun, 2008-05-04 at 18:49 -0700, Kris Leite wrote:
> In my case, it was much better to 
> create HopObject fields with default values.  If the user changed the 
> default values, then they are stored.  If nothing was entered, then
> the default values are not stored reducing storage overhead.

This would probably be even better accomplished like this:

this.__defineGetter('favColor',function(){
  return this.favColor_ === undefined ? 'red' : this.favColor_;
});
this.__defineSetter('favColor',function(val){
  val == 'red' ? (delete this.favColor_) : this.favColor_ = val;
  return val;
});

--

-- 
Joshua Paine <joshua <at> papercrown.org>
Kris Leite | 5 May 06:09

Re: markAsClean

Using getter/setters for this is possible.  I find the simple assignment 
statement in onInit to be much less code, execute overhead, and 
debugging needed.  The markAsClean function can be useful in other 
situations besides this one.

Joshua Paine wrote:
> On Sun, 2008-05-04 at 18:49 -0700, Kris Leite wrote:
>   
>> In my case, it was much better to 
>> create HopObject fields with default values.  If the user changed the 
>> default values, then they are stored.  If nothing was entered, then
>> the default values are not stored reducing storage overhead.
>>     
>
> This would probably be even better accomplished like this:
>
> this.__defineGetter('favColor',function(){
>   return this.favColor_ === undefined ? 'red' : this.favColor_;
> });
> this.__defineSetter('favColor',function(val){
>   val == 'red' ? (delete this.favColor_) : this.favColor_ = val;
>   return val;
> });
>
>   
Hannes Wallnoefer | 5 May 10:54
Picon
Favicon
Gravatar

Helma meeting tomorrow

Just a reminder that Helma meeting will take place tomorrow at
werkzeugH in Vienna.

http://dev.helma.org/wiki/Helma+Meeting+Spring+2008/

I'm just about to fix the starting time. My assumption was that we
should (try to) use the whole day and start (kind of) early, something
like 10 AM. But since there's a total lack of announced
talks/presentations (I'm the only one so far), I'm wondering if it
will be enough to start in the afternoon, at 2 PM? Or maybe the
"presentation/talk" scheme isn't quite right for what people expect or
plan to do, and it should be more like an extended Q&A session? Or
just applied collective problem solving?

Any way, please use the next 2 hours to either register your
interests/topics/proposals on the meeting wiki page linked above, or
chime in here on the list. I'll then make a decision on whether to
start pre- or post lunch.

best,
hannes
Anton Pirker | 7 May 09:53

Picrutes of Helma Spring Meeting 2008

Can be found here:
http://www.flickr.com/photos/glacionaut/sets/72157604925822114/

It was a great day!

Thanks,
Anton

--

-- 
DI(FH) Anton Pirker, Helma Freelancer

Gmane