Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    jesusbagpuss
    @jesusbagpuss
    Hi Adam. Does this work?
    gobfrey
    @gobfrey
    Ello
    It appears to be working
    right, I need to go to bed.
    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