Re: Direct csv import into Base table

On Mon, Jun 03, 2013 at 09:49:01PM +0200, Zolnai Tamás wrote:

> > > The feature which I intend to implement is making a new table and
> > > insert into the already opened database.

> > Yes, which is exactly what the procedure described in my previous
> > mail also does. Except it is not limited to CSV and other
> > calc-supported formats (but any supported database), and already
> > gives you access to each sheet of a calc file instead of the first.

> > Which was my main motivation for slapping a better UI on *this*
> > procedure rather than on the more limited "go through Calc" route.

> Well, misunderstandness around. I means making a new table and
> insert it into the already opened database *in one step*, or more
> steps but in an automated serial and without opening other window
> and without copy&paste.

Yes, that's exactly what I mean, but I'm talking about the
*implementation* of that idea. You wanted to embed a calc document
(with the said CSV data) inside Base scripting/code, and then copy the
table structure and data from there. That is: you want to "automate"
the procedure of opening the CSV in calc, and copy/pasting the data in
Base.

I'm trying to get you to automate *another* procedure, that is
copy/pasting the data from *Base* to *Base*.

*Both* procedures will give the *same* result in the end for the
specific case of CSV data, but the "calc to Base" procedure can only
import data that Calc can handle, while the "base to base" procedure
can handle any data that calc can handle AND ALSO any database that
Base can handle. So for example, if you implement it following my
idea, your "one step import" will also be able to e.g. import data
from a PostgreSQL database into a MySQL database. More general, more
useful. Please do it that way, and not through a Calc XEmbeddedObject
like you originally planned.

> > > With this I just say that for the user it can be looked as a
> > > different thing and so not make confusion.

> > Well, if "drag'n drop" and "import" of the *same* data behave
> > differently in the *same* application (that is, Base), I think this is
> > confusing and unpredictable: even if the user knows of these two ways,
> > why would he expect one to work "better" or "different" than the
> > other?

> I don't know what difference we actually speak about. In my first
> plan I intended to use the same paste method and the same "Copy
> Table" dialog which is used for "drag'n drop".

You intended to use the same code and dialog as which is used in "copy
from Calc, paste in Base". I want you to use the same code and dialog
as which is used in "copy from Base, paste in Base".

Imagine you automate this "import data" procedure using your idea of
"use Calc under the hood to get to the CSV data", that is same code as
which is used in "copy from Calc, paste in Base". This "use Calc under
the hood" is completely invisible to the user, (s)he is choosing a
menu entry in *Base*. So the user will naturally compare these two things:

 - Choose "import data" in Base task pane.

 - Open the *same* data in a 2nd Base window, copy it, and paste in
   the first Base window.

And expect that the two behave the same. The user will IMHO *not* find
"obvious" that "Choose 'import data' in Base task pane" will behave as
if he opened the data in ANOTHER APPLICATION (which just happens to be
LibreOffice Calc here) and *then* pasted it.

> > > The Writer OLE-object feature (...) the same file import as Calc do
> > > (...) which more usefull than the page with the same aim in
> > > Base. More usefull means more options and a table showing the
> > > expected result.

> > Well, if the CSV setup screen in Base sucks, we can fix
> > *that*. Possibly even use the same setup screen than in Calc? As in:
> > merge the two.

> As I see its not an easy hack. In Clalc the import UI is a
> ModalDialog, while in Base it is a TabPage which are not a
> 'mergeable' pair, at least I don't see the way.

It is work, yes. If they cannot be merged, then this is unfortunate
that we have to keep two implementations of the same feature, but we
can still add the "right" features to the Base implementation.

A few ideas:

 - The Base wizard, when one chooses "connect to existing database"
   and type "Text" and then clicks "next" fires up the Calc
   ModalDialog instead of continuing with its TabPage procedure?

 - The Base wizard, when one chooses "connect to existing database"
   and type "Text" and then clicks "next" fires up a specialised
   wizard that *does* have enough place?

> Additionally in Base wizard there is no enough space for all options

Well, this can be fixed either by the specialised wizard thing or by
just enlarging the Base wizard to have enough place.

> and for the table which are in the Calc csv import dialog.

The table is a different issue. In the Base wizard "connect to
existing database", one chooses a whole database (in the text/CSV
case, a directory), not just a table, so it is not as natural to show
a table. (which one from the multiple that are there?)

The "import data" wizard needs to have an additional step (compared to
the existing Base new/connect/open wizard) to choose which tables.

> Plus the content of the mentioned table (containing expected result)
> is already loaded in case of Calc, but in Base file-loading is
> happen after setting the csv import options.

The "import data" wizard can make a connection with the options as
they stand, and then tear down the connection and reopen it each time
the settings are changed.

> I just imagine a 4th option to the start page of Base wizard, with
> label "Import table(s) from existing database".

To me this does not sound natural. That wizard is launched by File /
New / Database. That's now where I would go looking to import data in
an existing database.

-- 
Lionel