Re: [Babeldoc-devel] A few more questions

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Erik,

On Thursday 27 March 2003 10:14 am, ek...@ba... wrote:
> Hmmmm ... interesting.  I was planning on building an administrator UI
> that would be used to update the CONFIG table.  My hope (and my
> manager's demand) was that new and modified pipelines could be added to
> the system by an administrator while the system was running.  This means
> that we will need to possibly modify a pipeline online while the system
> is running without a restart.  Additionally, we will need to add new
> pipelines without a system restart.

It is possible to add a method to the SqlConfigService that clears the caches.  
This gets called from your UI.  Remember the SqlConfigService just implements 
the IConfigService interface.  So you would just have to cast it and call the 
method.

> It appears that there may be two problems with this.
> 1. The system caches the database information and does not go back to
> the DB each time it needs it (for efficiency I'm sure).  Any chance of
> there being a "switch"/"configuration parameter" to turn this feature
> off?

See the solution above. 

> 2. My DBA will demand that I not append two fields together into one
> (config_nm).  Additionally, it will be simpler for my UI to have this
> field (pipeline name/id) broken out.

Yeah - this is possible too, its just that you will have to implement this.  I 
really dont have an opinion on this either way.

> Am I proposing something here that is going to cause me a lot of grief
> to implement?  Am I "stirring things up" here that I am going to regret
> later?

No, its just that you will have to be the one to implement this.  Also how 
important is it that you do this right away - why dont you do the 
Proof-of-concept first, get comfortable with that and then circle back?

Bruce.

> Erik
>
>
>
>
>
> bruce <br...@mc...>@lists.sourceforge.net on 03/27/2003
> 10:01:53 AM
>
> Sent by:    bab...@li...
>
>
> To:    "Babeldoc Developers List" <bab...@li...>
> cc:
> Subject:    Re: [Babeldoc-devel] A few more questions
>
> On Thursday 27 March 2003 09:55 am, ek...@ba... wrote:
> > Thanks again for your help.  I have quickly reviewed your comments
> > below.  I *may* need to make a modification to the CONFIG table to
>
> break
>
> > out the Pipeline Name from the Config Name field to pacify my DBA.
> > Hopefully it won't be a lot of additional coding on my part.  Thanks
> > again Bruce.
>
> No problem.   There is no real need for breaking this out - its not like
> the
> configuration table is going to be a high-volume operation - in fact its
> read
> only too.  Additionally this table is never re-read (well the same rows
> are
> never re-read) - the configuration information is cached.
>
> > Erik
> >
> > bruce <br...@mc...> on 03/27/2003 09:37:44 AM
> >
> > To:    ek...@ba..., bab...@li...
> > cc:
> > Subject:    Re: [Babeldoc-devel] A few more questions
> >
> >
> > OK,
> >
> > Erik here are the answers to your questions.  There is a command that
> > might
> > interest you:  sqlload:
> >
> > build\bin\babeldoc sqlload
> >
> > This loads configuration files into a database.
> >
> > Here goes....
> >
> > On Wednesday 26 March 2003 11:13 am, ek...@ba... wrote:
> > > ... though CERTAINLY not the end of my questions ... most of these
> > > questions are based off of reading all the properties files inside
>
> of
>
> > > babeldoc_core.jar, as this is my "starting point" ... so bear with
>
> me.
>
> > > -- What is the "<pipeline>.type" if I want to get my configuration
> > > information via JDBC (i.e. Not simple or xml, right?)
> >
> > Correct - The type here is how do you define the pipeline - in the
>
> case
>
> > where
> > you want to store the pipeline configuration in the database, you will
> > want
> > to choose "simple".  This means that the PipelineStageFactory will go
>
> to
>
> > the
> > configuration service to get the pipeline configuration.  Remember
>
> that
>
> > you
> > will be providing a SQL configuration service so all is well here.
> >
> > > -- What is the function of "compile=yes|no" in
> > > pipeline/compiler.properties?
> >
> > This is do caching of the pipelinestages and preloading.  It is
>
> possible
>
> > to
> > take this a lot futher and use something like BCEL and actually at
> > runtime
> > "glue" all of the pipelinestages together that form a pipeline using
> > ByteCodes.  This is not implemented.
> >
> > > -- If I want to use database journaling for Sybase, I realize that I
> > > will need to create a new class (most likely named
> > > com.babeldoc.sql.journal.SybaseJournal) and make an entry for it in
> >
> > the
> >
> > > journal/config.properties file, right?  Additionally, I will need to
> > > create the file journal/sybase/config.properties.  My question is
>
> what
>
> > > properties do I use in this file and what are the valid values?  Is
>
> it
>
> > > just "resourceName=babel-journal"?
> >
> > Correct and correct.  You will (most likely) need to write a class
> > SybaseJournal which extends GenericJournal (which does most of the
> > work).
> > Now, however you set that up, all the sql code in babeldoc does not
> > manage
> > the JDBC connections directly.  They use a resource metaphor - you
>
> will
>
> > need
> > to get a named resource (babel-journal) and then check-in and
>
> check-out
>
> > connections for your use.
> >
> > Now, you *DON'T* need to create a file
>
> journal/sybase/config.properties
>
> > unless
> > there are parameters that you need to store in that file that are
> > specifically necessary to configure your SybaseJournal (which I
> > seriously
> > doubt).  The configuration file journal/sql/config.properties informs
> > the
> > GenericSqlJournal the name of the resource to use to connect to the
> > journal
> > database - you dont even need to override this setting.  What you *DO*
> > need
> > to override is the resource setting for babel-journal.  This is done
>
> in
>
> > resource/babel-journal configuration.  Take a look at the one in the
>
> sql
>
> > module.
> >
> > > -- It appears that pipeline/config.properties contains entries for
> >
> > each
> >
> > > pipeline that is available.  If I am using JDBC to store my pipeline
> > > configuration information, do I still need this file?  Is there a
>
> way
>
> > to
> >
> > > represent this in the database?
> >
> > No, every property file in the config directory gets placed into the
> > database.
> >
> > > -- I've noticed that the Primary Key for the CONFIG table is
>
> cfg_name,
>
> > > which I believe represents a single "line" in a pipeline's
> > > configuration, right?  If that is so, how do we distinguish between
> > > configuration "lines" for different pipelines?  Should pipeline_id
>
> (or
>
> > > something like this) also be part of the primary key for the CONFIG
> > > table?
> >
> > No, the CONFIG table stores the file and line number information in a
> > single
> > column - take a look at the SqlConfigService code.  This simply pastes
> > the
> > config "file" and the property name together (separated by a period)
>
> and
>
> > places in the first column.  This makes life simple - no joins.
> >
> > > -- Do entries need to be made in service/query.properties for
>
> Journal
>
> > > and PipelineStageFactory in order to support JDBC?  It appears that
> > > there are already entries in there for "simple" and "xml".
> >
> > No, see above
> >
> > > -- From the "Source" and "Binary" installations that I did from
> > > Babeldoc, I do not see directories for "config" files except for
> > > multiple instances in the "src" subdirectories under each major
> > > component (such as "core", "sql", etc.).  In a production /
>
> deployment
>
> > > environment, what is the structure for the directory(ies) in which
>
> the
>
> > > config files go?
> >
> > Let me investigate this.
> >
> > > I'm sorry if some of these questions seem ignorant ... I'm trying
>
> very
>
> > > hard to get up-to-speed as quickly as possible as I have tight
> >
> > deadlines
> >
> > > to meet.
> > >
> > > Erik
> > > The information in this e-mail, and any attachment therein, is
> > > confidential and for use by the addressee only. If you are not the
> > > intended recipient, please return the e-mail to the sender and
>
> delete
>
> > it
> >
> > > from your computer. Although The Bank of New York attempts to sweep
> > > e-mail and attachments for viruses, it does not guarantee that
>
> either
>
> > > are virus-free and accepts no liability for any damage sustained as
>
> a
>
> > > result of viruses.
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by:
> > > The Definitive IT and Networking Event. Be There!
> > > NetWorld+Interop Las Vegas 2003 -- Register today!
> > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > > _______________________________________________
> > > Babeldoc-devel mailing list
> > > Bab...@li...
> > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel