> Hello.
Thanks for your quick reply. Knowing you're in a different time zone, I
sent the email as soon as I woke up and had a response in time to work
on the train.
> > 1. If I now have a bunch of new data for the tables, how do
> I get it in
> there? Am I supposed to load the data into my "raw" schema (the one
> martBuilder plays with) and drop all the tables in my final schema and
> recreate them using the SQL martBuilder gives me?
>
> Yes. Marts are supposed to be read-only denormalised copies
> of some data.
> Therefore when the data upon which they are based changes,
> they will need
> to be rebuilt from scratch. You can however preserve your configs by
> copying the tables called meta* from your old mart to the new one.
For now, it's easier to just drop the one table I have. But yes, in the
future that might make sense. Or I could save them (if save worked) and
re-load, right? I assume I would have to script something, and there's
no MySQL command like "copy table meta*"?
> > 2. In other bad news, martEditor isn't saving for me. If I try "Save
> All",
> > it lets me browse to a location on disk, but then doesn't
> save a file
> there. (I even tried saving in /tmp/ in case there was some weird
> permission issue.) Also, if I Export All, nothing changes (even if I
> restart Apache, which I tried out of desperation).
>
> "Save All" should dump out all configs from the database to a
> set of files
> in the chosen location. This does not include configs that
> have not yet
> been exported to the database, and so if you did this before
> using Export,
> that would explain the lack of files.
>
> "Export" will write the config back to the database inside a bunch of
> tables starting with meta* (same as the ones I mention
> above). It should
> be saving everything so that when you next do "Import" you
> get back what
> you exported, but if this is not the case we may need to
> investigate your
> specific case to find out the details.
>
> If you change the config and export it, then MartView will
> only pick up
> the changes if you re-run the perl configure.pl script you
> used to set it
> up initially and then restart Apache.
Ah. Lots of good data. Now, when I export, rerun configure.pl and
restart Apache, then I DO see the changes in my Filter/Attributes.
However, Save (whether I export or not) still never writes any file to
disk. Of course, this is less important now that Export works. But it
would be nice to save things for versioning and backup, if nothing else.
> > 3. If I select "insert
> dropdown" or whatever, it creates all of the filter values anew, which
> means I have two copies of some of the values.
>
> You have to delete all the options from the dropdown ('delete
> options')
> then recreate it ('make dropdown'). If you don't delete first
> then you'll
> get duplicate values.
OK. I'm not sure it's a bug, but definitely a feature that ought to be
changed. It seems obvious to me that if anybody says to make a dropdown,
they want to have a dropdown for what's currently in the database. Would
it be scan the existing options and not add an option if it's already in
the list? (That way, if the user has added a description field or
whatever, it doesn't get lost.)
> > 4. Is there an easy way to reorder options? If I have six
> options, how
> do
> > I move option 4 to be in between option 2 and 3? Anywhere I
> try to drag,
> option 4 ends up being placed INSIDE either option 2 or 3.
>
> Dragging-and-dropping should work to reorder in most circumstances but
> some kinds of options are valid when nested, and so it will
> nest them if
> it can. The only way round this is as you say to drop them into the
> collection in the right order.
Hm. That's a bit ugly. In Mozilla bookmarks, for example, if you have a
menu like:
bookmark1
folder1
folder2
and you click and drag bookmark1 downward, then it will:
1. Highlight folder 1, meaning bookmark1 will fall into that folder if
you drop now
2. put a line between folder1 and folder2, meaning bookmark1 will sit
between the folders if you drop now
3. Highlight folder2.
This gives the user full control over where things go, without taking up
extra room. Of course, I have no idea how hard it is to code.
>
> > 4a. In the end I may be happier editing the XML file, but I
> don't know
> where it is right now, and for some changes, it might be nice to use
> martEditor.
>
> This would probably be harder than trying to get MartEditor
> to work! The
> problem with this approach is that [snip]
Ouch! I'll stick with martEditor then. Would it be more trouble than
it's worth to save everything to one XML and then have
configureBiomart.pl split and cache the XML?
OK, I'll stop making seemingly innocuous suggestions that will actually
take 5 months to code.
> I hope the above helps a bit!
Helped, thanks. Still confused about the saving thing. Is there some way
to make martEditor log what it's doing so we can see why it fails? Have
others reported success at saving on Mac?
-Amir
