>> 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*"?
There's a command to do this called 'mysqldump'. You need to identify the
meta* tables using " show tables like 'meta%'; " and pass their names in
as input to this command, which then generates an SQL script to recreate
them in any target database complete with contents. Google will explain it
much better than I can!
>> "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.
...
> 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.
This is a bit odd. I've not come across it before. To be honest it's very
hard to know what's going on without seeing your individual machine setup.
I think for now that if it doesn't work for you, then mysqldump is your
best bet for creating backups as described above.
>> 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.)
That's a good feature request! I'll see it gets added to our list of
things to do. Whether or not it makes it into the existing MartEditor or
only the new one currently being developed I'm not sure.
>> > 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.
We have to rely on the Java drag-and-drop interfaces which are not very
well developed in Java 1.4 (which is the code level at which our software
currently has to be compatible with). I know they've improved in Java 1.6
so maybe there'll be something there we can build on, but until a decision
is made to desupport Java 1.4 in BioMart we can't make use of them
unfortunately, and even then we'd probably have to wait until Java 1.5 is
desupported as well. That could be a very long time from now as a large
portion of our users use Macs for which Java support tends to lag behind
the status quo by at least one Java version. Some still use PowerPC-based
Macs which will never move past 1.4.
>> > 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?
The current redesign of MartEditor from the ground up works on that basis.
You are right, it is much more sensible! However, it also requires changes
to the biomart-perl library to cope with the reorganised XML, and so
additional work is required to make sure the entire system works correctly
with the changed configuration XMLs.
The redesign+build of MartEditor does not have a scheduled release date
yet, as it is still at the prototype stage. Until then we will make
bugfixes and small changes to MartEditor that do not require massive
amounts of code to be changed, but we will not be adding large new
features as that would cause duplication of effort. So, all attention is
now on the new MartEditor. We'll let everyone know when it's ready.
cheers,
Richard
--
Richard Holland
BioMart (http://www.biomart.org/)
EMBL-EBI
Hinxton, Cambridgeshire CB10 1SD, UK
