Re: [Linkbat-devel] Data format, XML to DB conversion
Brought to you by:
jimmo
Menu
▾
▴
Re: [Linkbat-devel] Data format, XML to DB conversion
|
From: Shanta M. <sh...@fo...> - 2002-11-20 19:05:14
|
On Wed, 2002-11-20 at 12:01, James Mohr wrote:
> >
> > That is why I like to store my data in SQL. It allows me to manipulate
> > the data as I see fit. This includes exporting data to cvs files.
>
> In principle I don't have a problem with that. However, it requires the
> intermediate step to be SQL. If you have already inserted it into an SQL DB,
> why bother exporting it to CSV? (unless you want to move it a server that has
> no SQL DB) Although not necessarily efficient, I see a "friendlier" approach
> to first parse the XML into CSV and then import that into SQL.
>
eXtropia puts things into the chosen DataSource. There is no need for
the XML interface to do that.
> >
> > In my setup 0 change exempt one variable in the Global site setup.
> > $DataSource = "file"; or $DataSource = "MySQL";
>
> What about the code itself? If a single file = MySQL in terms of being a data
> source, I do not see how you could get around the problem of having to redo A
> LOT of code. If a file equaled a MySQL Table, then I see a 1:1 relationship
> between fields in MySQL and fields in the file, so there would be very litle
> code change necessary.
Long ago I added the falowing code to my application files
my @BASIC_DATASOURCE_CONFIG_PARAMS;
if ($site eq "file"){
@BASIC_DATASOURCE_CONFIG_PARAMS = ( -TYPE =>
'File',
-FILE =>
"$APP_DATAFILES_DIRECTORY/$APP_NAME.dat",
-FIELD_DELIMITER => '|',
-COMMENT_PREFIX => '#',
-CREATE_FILE_IF_NONE_EXISTS => 1,
-FIELD_NAMES => \@DATASOURCE_FIELD_NAMES,
-KEY_FIELDS => ['record_id'],
-FIELD_TYPES => {
record_id => 'Autoincrement',
datetime =>
[
-TYPE => "Date",
-STORAGE => 'y-m-d H:M:S',
-DISPLAY => 'y-m-d H:M:S',
],
},
);
}
else{
@BASIC_DATASOURCE_CONFIG_PARAMS = (
-TYPE => 'DBI',
-DBI_DSN => $DBI_DSN,
-TABLE => 'linkbat_questions_tb',
-USERNAME => $AUTH_MSQL_USER_NAME,
-PASSWORD => $MySQLPW,
-FIELD_NAMES => \@DATASOURCE_FIELD_NAMES,
-KEY_FIELDS => ['username'],
-FIELD_TYPES => {
record_id => 'Autoincrement',
datetime =>
[
-TYPE => "Date",
-STORAGE => 'y-m-d H:M:S',
-DISPLAY => 'y-m-d H:M:S',
],
},
);
In the Global setup the variables are defined as they are used my all
apps in the site only the table name needs to be changed in telling
eXtropia how the data is stored. cvs file or SQL.
>
> > > > Validation, field
> > > > contents, required fields and many other checking is already in
> > > > eXtropia one just has to tell it what you which to check for. Don't
> > > > know if this is what you are referring to with XML validation as I know
> > > > little of XML.
> > >
> > > I'm refering to the actual XML files before they are imported into the
> > > database. If someone forgets a closing tag or something else, we should
> > > know about it before we try to read it into the database.
> >
> > Ok. but that is why one develops on a separate server. could be added to
> > eXtropia but XML in the form View would likely be easier
>
> What about performance. An XML files is at least 10 times larger. Plus we have
> the issues of the inter-relationships between the various KUs. To what extent
> can this be handle by eXtropia when directly reading the XML files?
>
Not sure! As a Perl programmer I see XML as an more complex form of
HTML. I would not chose to use XML to directly access the underlying
data files but that is largely because I have not taken the time yet to
look into XML as a programing language. In this context I was thinking
more in the form of Javascripts ability to do checking in the browser. I
don't even know if XML can do that.
In eXtropia XML is placed in TTML files. This blends Perl into the
"View" that gets exported into the browser.
> Even if eXtropia could read the XML files directly and be able to present the
> relationships correctly. I cannot see how that would **not** lock us into
> eXtropia as the delivery mechanism. If in a CSV text file or SQL DB, then we
> can do standard queries on the data.
>
In eXtropia the queries are done on ActionHandlers to separate the logic
you are developing from the look and feel of the site. For the most part
you just tell eXtropia what you want it make the quire to the DataSource
so you don't have write new code to switch from SQL to CSV
Here is an example
$cgi->param(
-NAME => 'raw_search',
-VALUE => "project_code=='Requested'"
);
There is a subroutine built into the system that forms a SQL quire and
sends it to MySQL or parses the CSV File for the records that match your
request.
No rewriting of code to accommodate the change in DataSource. I you want
to duplicate the mechanics of doing this you will take years to get it
right. I don't have any desire to do that unless the default dose not do
what I want then I will hack the code, Isolate it from the default code
and call it as I need it. Selena, Gunther, and Peter are far better
programmers than I am. Gunther worked for Lincoln Stein. They all
program for banks using this application.
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> Battle your brains against the best in the Thawte Crypto
> Challenge. Be the first to crack the code - register now:
> http://www.gothawte.com/rd521.html
> _______________________________________________
> Linkbat-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linkbat-devel
--
Shanta McBain <sh...@fo...>
|
