going well. I'm 3/4 of the way through my Korea sojourn, and have only 3 working days until I'm back on leave :)
Hi Peter, just pondering using this to support hack-day-remote-users (ask Les :o) - seems to be simple enough!
seems simple enough for text. Will you need to post code snippets?
my $req = HTTP::Request->new( "GET", $url );
my $ua = LWP::UserAgent->new;
my $response = $ua->request($req);
that works too :)
is there any hackday short summary of the "dones"? thanks
well no one has said anything here for a while
i am considering doing a change to eprints core but i wanted some quick feedback
looks like i might be better served by tech list.
eprints soton (due to its seniority in years and general neglect) often find its self in the situation where you cant add a field to the database because the eprint table is too wide or there are not enough indexes
one of the main causes of width issues is that sets and named sets are (by default) created as varchar(255)
i was considering setting it so the default with of these fields was varchar(20) (or a similarly small number)
you can still make them bigger if you want to have a larger one using maxlength => 255, on the field config
Would it help for people to look at their existing named sets and see what sort of maximum length people have in non-soton implementations?
OK in core eprints the contributor type named set uses URIs so they are 41 characters long
Someone using URIs for Creative Commons licences could be hitting 52 characters (I think that's a maximum)
we could make the default a 100 and it would still be a significant improvement.
the alternative could be that we just an appropriately sized maxlength on all the default fields in eprints_fields.pl
100 would cover most proper uses of namedsets I think. I mean people shouldn't be writing sentences!
But URIs are a valid way of doing it, and they can get a bit lengthy
Yeah and linked data URIs can get a bit out of control depending on what your named set is about
The issue i have now is that ive been round eprints.soton putting limits on all my set fields
but i have to work out a slick way to generate script which generates alter statements to change my database to fit.
ive got dev pre-prod and prod so there is plenty of sandpits to play in
I suppose it really depends if it's a housekeeping issue at soton - then you could probably get something to work out what the maximum length of your sets are, and set that as a max. And there are some fields that could almost certainly have 20 or less and no-one would notice
But if it's global, then I think it needs to be a bit more lenient
What happens when you try and import (e.g not create via the GUI) some data with over-long data in fields?
For sets you'd still need to have a consistent name, or you get errors anyway...
I havent checked but i suspecit if you make an item in a named set with a key which is too long for the field very bad things happen
like everything will start up happily and looks like it works
and when you come to submit to the workflow you get a 500 and all the data from that form stage gets blow away...
that bug probably exists already but no one has ever written a test to see what happens if you make key which is over 255 long.
there should probably be some proper validation for that and a graceful failure case....
What should probably happen is that on instatiation the field should validate that all the keys fit in the hole and if they dont it should fail gracefully