~ubuntu-branches/debian/sid/kexi/sid

« back to all changes in this revision

Viewing changes to src/doc/dev/kexi_import.txt

• browse files at revision 1
• compare with another revision
• download diff
• download tarball
• view history from revision 1

Show diffs side-by-side

added

removed

src/doc/dev/kexi_import.txt

 

1

kexiImport proposal - piggz (www.piggz.co.uk)

 

2

=============================================

 

3

 

 

4

This is a proposal for some import functionality for kexi.

 

5

As of this moment i have no idea how it will work, but ive

 

6

been thinking and figured i should get something down in

 

7

writing.  Hopefully you will all improve on this and we can

 

8

get something working.

 

9

 

 

10

The way i see it we need to do a few things:

 

11

 

 

12

1) A common api to different import systems

 

13

   This would be similar in concept to kexidb drivers, but would

 

14

   only provide limited, specific functionality

 

15

 

 

16

2) DB specific classes that provide import functionality

 

17

   for postgres, mysql firebird etc...

 

18

 

 

19

 

 

20

For 1) we need to to:

 

21

 

 

22

i) Connect to backend    -|

 

23

                          |

 

24

ii) Get list of databases | All this is already catered for in

 

25

                          | kexidb

 

26

iii) Get list of tables  -|

 

27

 

 

28

iv) For a given table, get list of columns as stringlist

 

29

 

 

30

v) For a given table/column combination, get extended information for

 

31

   that column:

 

32

 

 

33

   type

 

34

     +--If a known kexi type then ok

 

35

     +--If unknown then driver may be able to automagically map to suitable type

 

36

     +--Ask the user what to do (map to type, convert column, drop column)

 

37

 

 

38

   index (yes/no)

 

39

 

 

40

   pkex (yes/no)

 

41

 

 

42

   default value

 

43

 

 

44

   Alot of this is already catered for in old kexi api, so maybe some

 

45

   chunks fo code could be reused, though a bit of a rewrite is inevitable

 

46

   to limit the functionality to the above

 

47

 

 

48

Once the table/column information is available then a tableschema object would be

 

49

created and standard kexidb api could create nescessary structure.  For this there

 

50

would be 2 modes of operation

 

51

 

 

52

A) Structure will be created under new db name, and kexidb api would be used as

 

53

   normal

 

54

 

 

55

B) Structure will be created in existing db.  Kexi api would need a mode where

 

56

   kexi__* structure is created, but tables are not created as they already exist

 

57

 

 

58

 

 

59

Ideas, suggestions and designs welcome :o)

 

60

 

 

61

PiggZ

 

 

b'\\ No newline at end of file'

• Older »

Loggerhead is a web-based interface for Breezy
Version: 2.0.1