Menu
▾
▴
chasers-devel — List for technical development of CHASERS
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
(6) |
May
(3) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Kenneth T. <ken...@gm...> - 2009-06-24 22:14:06
|
Hey folks. I did a bunch of work around organizing the database create
files, with the following results:
*Separation of core code from main-object-specific files.*
In the database/pg directory, there is now a "chasers_core" directory,
which is supposed to hold all the stuff that's common across all
versions ("flavors") of CHASERS. All the client-version specific stuff
is in a "client" directory.
I think this will be a big improvement, and make it much easier to
integrate other flavors in the future. It also helps flesh out the
meaning of the path structure, which may previously seemed odd ("why
_are_ all those files buried in database/pg/client?"). With database/pg
containing chasers_core, client and donor (see below), I think it gets a
lot clearer.
This separation isn't quite perfect yet. Notably, the calendar stuff is
duplicated in the client and donor directories, simply because they
reference client_id or donor_id. I hope we get a better solution at
some point.
In the database/pg directory, there is now an
"install.client_database.sql" file that installs chasers_core, and then
client. I updated the INSTALL file a bit, and will try to get to the
Wiki as well.
*Database files for donor checked in*
All the files needed to create the donor database have been checked in.
(they're in database/pg/donor, natch!) And there's an
install.donor_database.sql file in database/pg.
With this checkin, the full donor flavor of CHASERS is now available in
the GIT repository, and publicly available. I'm pretty excited about
this, and hope we see that work on the core flows to all flavors.
With the donor stuff added, I'm thinking it might be good to do a
"snapshot2" release fairly soon. In the meantime, I'm going to go back
to working on the report stuff, filling in a couple of holes. I'll
probably do a cleanup of that code that removes the CFG file support.
It should remove a lot of cruft from the code. And if DESC decides to
move to DB reports, I think there is a very smooth upgrade path with
the convert script.
That's it for now. Cheers,
Ken
|
|
From: Kenneth T. <ken...@gm...> - 2009-06-10 01:07:15
|
Just a quick update on the donor database. With the exception of the database creation stuff, the entire contents of the donor database have been incorporated into CHASERS, including the version in the Git repository! Effectively, the two are now integrated into a single version. And by changing the chasers_config_local file, I was in fact able to run the Donor DB from my working Git copy. That still leaves all the database creation stuff. If I do a good job, I'll compare them carefully, identify overlapping files and move them to a common directory, etc. If not, I'll just dump all the donor stuff into a database/pg/donor directory. Either way, it should work fine. I'm glad there won't be two separate versions to maintain in the future! Ken |
|
From: Kenneth T. <ken...@gm...> - 2009-06-08 16:28:46
|
Hey folks. I recently dusted off my copy of the donor database I'd been working on, but this time with an eye towards integrating the donor DB in with the client version. Much of the groundwork for this was already done (thank you Jonathan!), and the difference in the codebase was amazingly small. Most of the differences were in fact more recent features that were in my copy of the donor DB but not in the gpl client version. So I was able to merge a few features in, including the file attachments (thank you Jessi!) and multiple staff alerts. And I have now gone through all the files in the top-level directory, and the only files differing between the two versions are auth.php (the has_perm stuff), chasers_config.php (just the title, and file locations), and of course chasers_config_local.php. Unless I'm missing something, once those files are addressed, it will be possible to run the public version of CHASERS, define it as the donor database in chasers_config_local, and be up and running. I think it will be really nice to have a unified version going forward. There's still more work to do to unify all the database creates and such, but I'm not worrying about that at the moment! Come to think of it, it would be nice to unify the locator and measures databases into the same code as well! That's it for now. Let me know what you think, or if I've overlooked something important! :) Cheers, Ken |
|
From: Kenneth T. <ken...@gm...> - 2009-06-04 03:36:57
|
I've done some more work on DB-based reports. It keeps some of the old clunkiness, but does bring it all into the DB. I think the current version now incorporates all of the functionality of a CFG file. The code updates I've made are mostly self-contained, but there is a new report_id field that I added to tbl_report_usage. I committed a db_mod to git, but these were never my strong suit. :) I've also written a script that will read an existing set of CFG files and post them to the DB. It will preserve an existing report tree (shelter, clinical, etc.) by storing the paths in the sortkey field. I've tested it pretty carefully with the CFG files Nathan sent me, as well as a couple I created, and I think it's pretty solid. (Solid as in working. I freely confess that it's fairly ugly!) If anyone at DESC gives this a test run, please post back what the results were. Any feedback on this current implementation--especially shortcomings or omissions I might not have caught--would be welcome. Thanks. Ken |
|
From: Kenneth T. <ken...@gm...> - 2009-06-01 21:48:05
|
Hey folks. I thought some of you might be interested to know that I was able to successfully get CHASERS running on Windows. This may be useful for any potential users who are really committed to staying with the Windows platform. I haven't fully tested it, and expect there might be some minor things that would need tweaking, likely related to paths and file handling. But it's apparently a much smaller deal than I might have imagined. As a tech note, although it took me a while to get Apache, PHP & Postgres running, CHASERS itself was pretty easy, and only required changing the path to the files, plus fixing one line of code (there's an 'https' hard-coded that needs to be fixed). I didn't get SSL (for Apache) or table_log (for Postgres) working, so I don't have https or revision history working, but I don't think these are CHASERS issues. It's not that the can't run, just that I didn't bother setting up SSL, and don't have access to a Windows development environment to compile table_log. At some point I'll update the documentation with this new information. Let me know if you have any questions. Thanks. Ken |
|
From: Ken T. <ken...@gm...> - 2009-05-29 22:37:19
|
I've done a first stab at reports running from the DB. It hacky to say the least. All the SQL statements are glommed into one text field. The same for all the user variables. It basically kicks the can down the road for some of the issues previously mentioned. In terms of basic functionality, though, I think it's pretty close. I'm not sure if it does or doesn't correctly read "include" files. The "show config file" option on a generated report doesn't currently work. It should be pretty straightforward to create a conversion script to move from CFG files to the DB. I can put one together if there is any interest, and if someone at DESC can send me a couple of CFG files--I think I've happily wiped the format out of my brain! :) I'm going to check this into a git branch called ''reports", but in the meantime I've attached a patch to this email, which hopefully would work cleanly on existing installations. On a side note, the branching features of git are fantastic! As always, feedback, thoughts, suggestions, etc. most welcome. Cheers. Ken |
|
From: Kenneth T. <ken...@gm...> - 2009-05-19 22:53:07
|
I've been doing some work on making reports storable in the DB, rather than as separate CFG files. I've currently got a version that will kind of run a report from a table, but doesn't handle "small" details like user-selected variables, multiple SQL statements, and so on. I can do really hackish implementations of these things as text blobs in the report table, but I think it would really be better to have for example each variable live in a separate table, and have multiple variable-records linked to each report. The same for SQL statements, although I'm not as sure given the complications discussed below. To continue working on this part, it would be really helpful to get access to the child-child table stuff that has already been done at DESC. Sarah or Nathan--if you could provide that stuff, it would be great, or if there's a problem or complication I'm not thinking of, let's touch base and figure out how to proceed. Now for the complications. The main one I see is that currently the CFG files have a defined order for both user-variables and for SQL statements, namely the order in which you include them in the config file. If these moved to child tables, how would they be ordered? Although this may only be a cosmetic issue for user-variables, it's rather critical for SQL statements. They could be ordered by their ID #s, but that would be ugly and extremely limiting. There could be some kind of ordering field in the SQL table, either to stand alone, or to override order-by-id, but that seems pretty clunky too. I suppose there could be a list of SQL IDs as a field in the report table. This could be an array field, but I don't remember off hand if array fields keep their order or not, and I think you also lose enforcement of foreign keys. In short, I'm not really happy with any of those options, and am hoping someone else has some great ideas, or at least some thoughts about this. Backtracking a bit, although it seems cleaner, I don't suppose either of these things _have_ to move to child tables. A couple of advantages, though, might be: * For SQL queries, you could add a nice clean boolean field to "suppress output", if you were merely creating a temp table. OTOH, you could have a simple hack like having your SQL statements start with a * (or something) if you wanted to supress output. * Having them in a table might facilitate the sharing of variables and SQL statements. Currently we can use the "Include <file>" option, but without files, that option seems to go away. * User variables in a table would allow creation of lookup tables for variable types, and make it easier to create a report through the GUI. That's all I got for now. Any and all thoughts and ideas appreciated! Ken |
|
From: Kenneth T. <ken...@gm...> - 2009-05-19 22:32:23
|
Hey folks. I set up a GIT repository on Sourceforge. There's not much in there yet. I started by committing a clean copy of the chasers_gpl_snapshot_1a tarball, and tagged it as such. I subsequently removed the CVS entries, and added the per-object updating patch. Sourceforge has pretty good documentation on accessing GIT, and they also have a nice browseable view of it. While I was at it I disabled CVS on Sourceforge. It had been enabled, but nothing was ever committed to it. I'm glad this is up an running, as it seems pretty necessary for continuing CHASERS development in the future. I haven't actually tried pulling a copy of CHASERS with GIT, but I assume it works fine. If anyone finds that's not the case, please report back! Cheers, Ken |
|
From: Jonathan H. <jhe...@gm...> - 2009-04-24 23:56:33
|
On Fri, Apr 24, 2009 at 3:47 PM, Kenneth Tanzer <ken...@gm...>wrote: > Hey Jonathan--what if anything do you know about Git, and do you see any > reasons not to use it on Sourceforge as the repository for CHASERS > code? I don't know a ton about it, but it seems like a good choice, and > hey it's good enough for Linus! :) I saw on Facebook you had a Git > conversation with someone, so I figured I'd try to pick your brain! > Git would be a great way to go. It will make merging complex changes back to (and then again out of) the Sourceforge repository much more straightforward than with CVS. I highly recommend going that route. Cheers, Jonathan |
|
From: Kenneth T. <ken...@gm...> - 2009-04-24 22:47:41
|
Hey Jonathan--what if anything do you know about Git, and do you see any reasons not to use it on Sourceforge as the repository for CHASERS code? I don't know a ton about it, but it seems like a good choice, and hey it's good enough for Linus! :) I saw on Facebook you had a Git conversation with someone, so I figured I'd try to pick your brain! Ken |
|
From: Kenneth T. <ken...@gm...> - 2009-04-24 03:22:09
|
Before the "update array" option was a link, so you could open it in a new window, which you can't do with the new form button. So here's a slightly tweaked version, that will open the update in a new window or tab, depending on your browser's behavior. I'm just going to post as an attachment, since it seems to go through just fine. Ken Kenneth Tanzer wrote: > It was driving me crazy to be waiting for the whole engine array to > updat every time, so I changed it. With this patch, you can now update > the whole array, or just a single object. I've tested it some, and it > seems to work, but let me know if anything is broken! > > I'm assuming it's better to provide patches as attachments (since line > breaks are preserved), but at least for this one, I will try both > attaching and including in the email text. I'm not really sure what > if anything the mailing list will do with or to attachments! > > Ken |
|
From: Kenneth T. <ken...@gm...> - 2009-04-24 03:02:06
|
It was driving me crazy to be waiting for the whole engine array to
updat every time, so I changed it. With this patch, you can now update
the whole array, or just a single object. I've tested it some, and it
seems to work, but let me know if anything is broken!
I'm assuming it's better to provide patches as attachments (since line
breaks are preserved), but at least for this one, I will try both
attaching and including in the email text. I'm not really sure what if
anything the mailing list will do with or to attachments!
Ken
--- ../chasers_gpl_snapshot1a/io.php 2008-09-26 09:40:50.000000000 -0700
+++ io.php 2009-04-23 19:46:12.000000000 -0700
@@ -2557,10 +2557,13 @@ function chasers_top_header($commands=""
global $AUID, $CG_AUTH;
// if ($database[$WHICH_DB]<>"Chasers" ||
$db_server[$WHICH_DB]<>'db.desc.org') {
if (is_test_db()) {
+ $update_list = update_engine_object_list();
$test_db_warning = div(center(bold(white(bigger(
"WARNING: Test Database
$database[$WHICH_DB]",3)) .white('('.$db_server[$WHICH_DB].')')))
. bold(pop_help("test_database","","What's all
this test stuff about?")) .
- (has_perm("super") ? oline() .
smaller(hlink('update_engine_config.php','Update Engine Array')) : "")
+ (has_perm("super") ?
+ smaller( formto('update_engine_config.php')
+ . 'Update Engine Object: ' . $update_list) : "")
,
'',' style="background-color: red; text-align:
center; width:100%; padding: 10px;" id="chasersTestWarningBox"');
$test_hide_link = Java_Engine::toggle_id_display(' +/- Test DB
Warning box','chasersTestWarningBox','block');
--- ../chasers_gpl_snapshot1a/engine_functions.php 2008-09-26
15:25:34.000000000 -0700
+++ engine_functions.php 2009-04-23 19:43:58.000000000 -0700
@@ -2689,7 +2689,6 @@ function update_engine_array($use_auth=t
global $CG_ENGINE_TABLES,$engine,$off;
$engine_array = orr($engine_array,CG_ENGINE_CONFIG_ARRAY);
- $tables = orr($tables,$CG_ENGINE_TABLES);
$engine = null; //objects w/o config files were not configuring
properly w/o this
$auth = $use_auth ? has_perm('admin','RW') : true;
@@ -2698,10 +2697,17 @@ function update_engine_array($use_auth=t
exit;
}
- outline(bold('Updating and storing in Engine Array: '.$engine_array));
+ outline(bold('Updating and storing in Engine Array:
'.$engine_array),2);
//GENERATE ENGINE ARRAY FROM CONFIG FILES
require ENGINE_CONFIG_FILE_DIRECTORY.'/config_engine.php';
-
+ if ($tables)
+ {
+ $engine=get_engine_config_array();
+ }
+ else
+ {
+ $tables=$CG_ENGINE_TABLES;
+ }
foreach ($tables as $tmp) {
if (is_readable($off . ENGINE_CONFIG_FILE_DIRECTORY .
'/'.CG_MAIN_OBJECT_DB.'/config_'.$tmp.'.php')) {
@@ -2725,6 +2731,7 @@ function update_engine_array($use_auth=t
$serialized_engine=serialize($engine);
+ outline();
outline(bold('UPDATING CONFIGURATION ARRAY IN DB'));
$exists=desc_query('SELECT * FROM
'.CG_ENGINE_CONFIG_TABLE,array('val_name'=>$engine_array));
if (sql_num_rows($exists)<1) {
@@ -3549,4 +3556,21 @@ function grab_append_only_fields($rec,$d
return $rec;
}
+function update_engine_object_list()
+{
+ /*
+ * Create a pick list for updating individual engine items
+ */
+
+ GLOBAL $CG_ENGINE_TABLES;
+
+ $update_list = selectto('UPDATE_ENGINE_OBJECT')
+ . selectitem('UPDATE_ALL','Full Engine Array');
+ foreach ($CG_ENGINE_TABLES as $table) {
+ $update_list .=
selectitem($table,$table,orr($_REQUEST['UPDATE_ENGINE_OBJECT'],
+ $_SESSION['UPDATE_ENGINE_OBJECT'])==$table);
+ }
+ $update_list .= selectend() . button('update!') . formend();
+ return $update_list;
+}
?>
--- ../chasers_gpl_snapshot1a/update_engine_config.php 2008-09-26
09:40:52.000000000 -0700
+++ update_engine_config.php 2009-04-23 19:49:23.000000000 -0700
@@ -42,10 +42,20 @@ if (isset($_REQUEST['noexists']) || (iss
$CG_FULL_INI = false;
include 'performance.php';
include 'includes.php';
-
+
+ if ($table=$_REQUEST['UPDATE_ENGINE_OBJECT'])
+ {
+ $_SESSION['UPDATE_ENGINE_OBJECT']=$table;
+ if ($table=='UPDATE_ALL')
+ {
+ $table=null;
+ } else {
+ $table=array($table);
+ }
+ }
+
//GENERATE ENGINE ARRAY FROM CONFIG FILES
-
- $res = update_engine_array();
+ $res = update_engine_array(true,NULL,$table);
if ($res) {
|
|
From: Kenneth T. <ken...@gm...> - 2009-04-22 21:28:58
|
Here is a preliminary list of things I'd like to see get done for CHASERS. I'm sure it's not complete, and I'd love to get additional things to add to this. If anybody wants to take one of these and work on it, please respond back. In the meantime, I'm going to start plowing through them, starting with eliminating the report CFG files. Ken *Create public code repository * This seems indispensable for doing collective development work. I suggest we do this with Git, which is an option provided for by Sourceforge. As we go further, we'll need to figure out how the DESC and public repositories will relate. *Eliminating anachronistic code and structures* The two obvious ones that come to mind are using engine for log entries, thus eliminating all the old log code moving reports into the database, thus eliminating the report CFG files *Incorporating recent CHASERS development efforts* including: repeating events child-child tables file attachments *Genericizing the lookup tables and other stuff* This will likely be an ongoing project, but some simple things could be done quickly. Removing most of the permissions from the distribution is one. Making staff emails work for non-DESC addresses would also be good. *Release a donor database version* This is mostly ready to go, but I think it would be better to get some of this short-term stuff done first. Looking out a little further, these are some things that would be nice to accomplish: *Easier install options:* Create Fedora RPM Create an Install script Documentation for installing on Ubuntu *Other Stuff* Create sample data set Move wiki to sourceforge? Hosted development version? Get CHASERS running outside of DESC |
|
From: Kenneth T. <ken...@gm...> - 2009-04-16 22:56:14
|
Hello folks. To help facilitate what I hope and believe will be
newly-increased efforts to improve and disseminate CHASERS, I've created
two new mailing lists. One is for technical development efforts
(chasers-devel), and the other for documentation discussion and issues
(cleverly named chasers-documentation).
Creating these lists will provide for more specialized discussion among
subscribers, while allowing those with only a more general interest in
CHASERS to be spared the gory details.
Subscription to these new lists is of course open to anyone with an
interest, and also entirely optional. I would certainly hope, though,
that at the very least Jonathan, Sarah, Jessi and Nathan will all end up
as subscribers to chasers-devel.
It will be no surprise to anyone that there is plenty of room for
CHASERS improvement--it's a target-rich environment! The general areas
seem to be:
increased ease of installation and configuration
improved documentation
elimination of legacy code
enhanced documentation
increased and more flexible functionality
I've been thinking about this recently, and am working on a list of
near-term items that I think would be relatively manageable. I'll try
to post it shortly (to chasers-devel), and would love to hear other
people's comments and ideas.
I'll mention one item now, though. It would be nice to get some of the
improvements that have been made more recently at DESC incorporated into
the next release. Ones that come quickly to mind are the calendar
repeating events (and child-child-tables) and file attachments. There
are likely others that I'm either forgetting or unaware of. If someone
at DESC could pull those patches at some point, it would be very
helpful. We'll also need to figure out how to keep DESC and public
versions of CHASERS in sync, but that's a discussion we can have on the
devel mailing list!
That's about it for now. After a nice long break, I'm planning to
devote some significant time and energy towards CHASERS efforts, and am
excited to be doing so. I hope some of you still retain CHASERS
enthusiasm, and want to continue on the never-ending quest for
improvement! Hope y'all are doing well!
Ken
|
