On Thursday 17 June 2010 15:52:09 Brian Bruns wrote:
> I merged a few of the more obvious ones. Hoping to get back to it
> tonight or this weekend. Again, all commited to the repo at github.
Hey, this is really good news. Kind of funny I had to use the Ugly word "fork"
for this to work. ^^
Reading the last posts, I'm a bit surprised some people have being using some
pacthes for 5 years without them being integrated upstream! Please make sure
you give write access to a few people when you'll think you can't spare any
more time on that project.
Also, it would be nice to have a big notice on SF telling people to go to
github if that's where you plan to keep the repository stored. I was annoyed a
couple of time with other projects changing their repo without a proper notice.
Patches starting with 0 - I mean having a number < 100 - are from the Debian
repository. I guess Tim will know about these better than me.
> (...)
> > patches/055-iconv-config
> > Do not #include <config.h> in public headers.
> Didn't apply yet, but will.
I not familiar with openoffice code but, FYI, I think they had problems with
that, too. Their source contains several mdbtools patches, including:
ooo-build-3-2-0-10/patches/dev300/cws-mdbdriver02.diff
I didn't fully reviewed them, but I had the general feeling their patches are
now part of developing branch.
> > patches/120-decrypt
> > Support for encrypted files.
> Didn't apply yet, but will.
There is no support for writing. It might be easy to implement. Meanwhile, I
disabled write operations if file is encrypted, just to be sure not to loose
data.
I found several keys around the internet as a xor value for the RC4 seed:
0xe15e01b9 and 0x4ebc8afb. I'm using the second as it works for me (access 97).
It would be nice to have other people test.
> > patches/150-backend-quote
> > Use backend/dialect specific quotation when generating SQL, for
> > support of spaces in tables names and other problematic characters.
I need it to export tables containing spaces in their names.
I focused on postgres. Other backends are poorly tested.
> > patches/155-blob
> > Support of Blobs
Poorly tested.
> > patches/160-foreign-keys
> > Support for postgres foreign keys and ON UPDATE / ON DELETE.
That one will give you good clues as how mdb files handle cascade of foreign
key, and opens new area of work. :)
Handling foreign keys leads to small problems however when exporting data with
a mdb-schema / mdb-export couple.
1/ The foreign keys constraints are set first. Then the data is loaded. Foreign
key violation will occur when tables are loaded in the wrong order.
I sloved that with a script that do "mdb-schema ... | grep -v REFERENCES" then
"mdb-export ..." then "mdb-schema ... | grep REFERENCES"
2/ The little "drop table" statements generated before the "create table" ones
will fail when there are constraints.
I think that patch is still really usefull, and should be applied.
But I guess what most people want is a complete mdb-export-magic tool that will
do everything for them, both basic schema + data + constraints.
This goes far beyond a simple "patch". I'm willing to help on that, but I won't
do it unless we agree about how it should be done, so that the work is
integrated upstream.
One more thing about foreign keys, the GUI will not print them yet. It's not
implemented. There will be a lot of code duplicated in mdb-schema and gmdb,
this is not good. But a fix with factorisation into backend.c is not "just a
patch".
> > patches/170-sequences
> > Support for autonum as postgres sequences.
The bad part of that one is that sequences are not initialized. For one, I
didn't find where last value is stored in access.
So for postgres, I have a script that will do:
mdb-schema ... | grep -r "SET DEFAULT pg_catalog.next" | sed -r -e "s/ALTER
TABLE (.*) ALTER COLUMN (.*) SET DEFAULT pg_catalog.nextval\('(.*)'\);/SELECT
pg_catalog.setval('\3', (SELECT MAX(\2) FROM \1), true);/"
Ugly, isn't it?
Here again, I have a general infrastructure problem. Should sequences
initialisation should be part of mdb-export and not mdb-schema? Sequences next
values sure should be set after data is imported....
Don't get me wrong, however. I like my patches and would love to have them
upstream, even the "poorly tested" ones.
On Wednesday 16 June 2010 13:03:11 Nirgal Vourgère wrote:
(...)
> I'm putting all this on http://www.nirgal.com/mdbtools/
--
To UNSUBSCRIBE, email to debian-openoffice-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201006172107.59698.contact_mdbto...@nirgal.com
