Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Peter West
    @pjwest
    hi
    gobfrey
    @gobfrey
    Ah, It's Peter :)
    How's things?
    Peter West
    @pjwest
    great thanks - and how about you?
    gobfrey
    @gobfrey
    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 :)
    jesusbagpuss
    @jesusbagpuss
    Hi Peter, just pondering using this to support hack-day-remote-users (ask Les :o) - seems to be simple enough!
    Peter West
    @pjwest
    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 :)
    stof999
    @cmdtstof
    is there any hackday short summary of the "dones"? thanks
    Patrick McSweeney
    @patrickmcsweeney
    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
    Lizz Jennings
    @icklecows
    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
    Lizz Jennings
    @icklecows
    Someone using URIs for Creative Commons licences could be hitting 52 characters (I think that's a maximum)
    Patrick McSweeney
    @patrickmcsweeney
    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
    Lizz Jennings
    @icklecows
    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
    Patrick McSweeney
    @patrickmcsweeney
    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
    Lizz Jennings
    @icklecows
    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
    jesusbagpuss
    @jesusbagpuss
    What happens when you try and import (e.g not create via the GUI) some data with over-long data in fields?
    Lizz Jennings
    @icklecows
    For sets you'd still need to have a consistent name, or you get errors anyway...
    Patrick McSweeney
    @patrickmcsweeney
    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....
    Patrick McSweeney
    @patrickmcsweeney
    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
    for added brownie points it could do the same check to decide an approrpiately sized varchar
    hmm it appears gitter is shit
    it keeps dropping my messages
    the downside of that approach is adding an item to named set will sometimes involve calling "epadmin update" which maybe undesirable
    jesusbagpuss
    @jesusbagpuss
    storing a value in a namedset doesn't require an epadmin/update - it doesn't look good if there isn't a phrase defined for it - and you have to add it to the 'options' of the field in the workflow - which isn't good.
    If you don't add it to the options in the workflow, you can't retain a value in that field = data loss when someone edits the EPrint. I'm currently wrestling this for a licence field that does more sensible things than the current one!
    Patrick McSweeney
    @patrickmcsweeney
    sorry John i dont think i understood what you were getting at there
    jesusbagpuss
    @jesusbagpuss
    Namedset options (in file): a,b,c,d
    Workflow rendering: select: a / b / c / d
    If (via an import / connected system) we set the value to 'e', next time someone edits the item in the GUI, they're presented with the options a/b/c/d - and can't retain the already-set value 'e'
    At least that's what was happening on our 3.3.10 server!
    Patrick McSweeney
    @patrickmcsweeney
    oh really? that had not occurred to me.
    can you not just add e to the set?
    does that mean you can do $eprint->set_value("yourset", "e"); it just lets you do that?