| View previous topic :: View next topic |
| Author |
Message |
maggus
General User
Joined: 04 Apr 2003
Posts: 9
Location: Germany
|
 Posted: Fri Jun 13, 2003 1:00 am Post subject: Storing and loading documents in/from a database |
 |
|
Hello,
IŽam trying to store writer-documents in a database (SAP DB) and to load them again, when needed.
I want to store/load the whole document, not only the content.
Is this possible at all? If so, I am very thankful for any suggestions.
tia
Markus |
|
| Back to top |
|
 |
holgerth
General User
Joined: 07 Jun 2003
Posts: 26
Location: Germany
|
| Posted: Fri Jun 13, 2003 11:53 am Post subject: |
|
|
Hi,
sure this is possible, but not by using OOo and the DB themselves. I suppose you already have designed a relational data model for storing binary data/documents into your db.
So the only thing you need is writing two programs:
One program that takes a local file and does insert it into your database using a sql insert (including any other attributes you used in your models' relations, especially the keys to select your document  ).
The second program then is used to extract the document out of your database and store it as a local file.
You can use StarBasic macros to call your programs after you have saved the document. On the other hand, you may use c++/java to implement components directly which are able to store a document into your database (either first storing to a temporary directory, then insert into db and delete and the other way round for loading, or replacing all document services completely by your own services which implement overriden methods of the XStorable interface).
Regards
Holger |
|
| Back to top |
|
|
DannyB
Moderator
Joined: 02 Apr 2003
Posts: 3991
Location: Lawrence, Kansas, USA
|
| Posted: Fri Jun 13, 2003 1:56 pm Post subject: |
|
|
Some of the development docs I was reading described in great detail the UCB (Universal Content Broker). Basically, a fancy abstraction for loading and saving documents.
Would it be possible to implement an alternate / additional UCB component that directly stored a document into a blob field of a row of a table? |
|
| Back to top |
|
|
Guest
|
| Posted: Sat Jun 14, 2003 2:14 am Post subject: |
|
|
Hi,
| DannyB wrote: |
Would it be possible to implement an alternate / additional UCB component that directly stored a document into a blob field of a row of a table? |
Theoretically yes, by implementing a ucp (universal content provider) component. Though this sounds great for the moment, you're running into problems:
- there is no uri specification for database access; you'll need to elaborate a spec conforming to RFC 2396 because the ucb relies on this rfc; your uris must be unique to exactly identify a document in your db (this can get as complex as many key attributes you have to identify a document)
- there is no or at least i don't see the possibility to pass further arguments to the ucp. Most obviously, if you are storing documents into a db, you also want to provide meta-information while storing, but through the api you cannot
- It'll be even harder to implement a function for browsing the documents in your db
- you'd have to spent a horrible amount of time into design (if compared to the other possible implementations). while data independency normally hides changes of the data model from your applications, those that come through effectively may break the whole concept. E.g. if you had a new attribute also becoming part of your key, you need a new unique uri specification, an uri generator for loading/saving documents and a extended parser for the uri. You also have to make the changes public in your organization in case somebody uses the uri directly while loading documents. In contrast, a simple gui application just needs changes on the dialog, extends on the data structure for the attribute and modified queries what you also need to do afterwards.
So for the moment i think, ucb is just a great system for implementing protocols which already have their uri specification.
I think a ucb approach would really be cool as it's totally integrated into the uri scheme of ooffice. But a solution with temporary storage of the documents by retrieving/inserting them from/into the database is much simpler to implement and easier to adapt to changes which really break data independency.
Regards
Holger |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
