RE: Feedback on this approach to many sites, one codebase (MSOC)

2011-02-19 Thread Rick Faircloth

 That doesn't really sounds like you're running multiple different
 sites off one unified codebase - you're providing a library that is
 intended to be reused across multiple, separate applications :)

I think that's accurate for this global site manager.  However, I'm
trying to determine the best practices for applying the methods I'm
using on the site manager to public web sites, themselves.


-Original Message-
From: Sean Corfield [mailto:seancorfi...@gmail.com] 
Sent: Friday, February 18, 2011 7:58 PM
To: cf-talk
Subject: Re: Feedback on this approach to many sites, one codebase (MSOC)


On Fri, Feb 18, 2011 at 11:36 AM, Rick Faircloth
r...@whitestonemedia.com wrote:
 When a user visits www.xyz.com, onApplicationStart() runs a
 query that retrieves, among other variables, the absolute path
 to those images.  Realize, the application that I'm referencing
 is a global site manager (single codebase) for managing
 site content on multiple sites (each with a separate codebase,
 as these are custom sites). The end user sites are completely
 different.  I'm using the global site manager, at this point,
 to simply provide a single app to supply CRUD functionality
 to the users for their site content. Even the databases for
 these sites have little in common. I just decided that instead
 of building CRUD functionality over-and-over for each site manager,
 I'd build one site manager to rule them all. :o)

That doesn't really sounds like you're running multiple different
sites off one unified codebase - you're providing a library that is
intended to be reused across multiple, separate applications :)

 The userImages path gets set when the application is first run
 by onApplicationStart() and a query, qGetApplicationVariables, is run
 that retrieves info such as the userImages path, or, in this case,
 qGetApplicationVariables.userImagesPathAbsolute. Then, the query
 value for the userImages path is cfset to
application.userImagesPathAbsolute
 for use throughout the site.

I have a site object containing all the site-specific settings. When a
request comes in, the domain in the URL is mapped to a site object,
and that is used throughout the request for any site-specific info.
Site objects are cached for efficiency, of course. This allows me to
clearly separate code / data that is common across all sites from that
which varies.

 If I have the same application name, wouldn't the userImages path
 variable be overwritten when another user visits another site using
 the same site manager codebase and onApplicationStart() is run again?

onApplicationStart() is run once for the entire system in my model. I
don't use bare application variables anywhere (because I use a
framework that has all the services injected as needed, or uses a bean
factory accessible within the framework).
-- 
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/

If you're not annoying somebody, you're not really alive.
-- Margaret Atwo



~|
Order the Adobe Coldfusion Anthology now!
http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion
Archive: 
http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:342449
Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm


Re: Big XML files processing Really s-l-o-w. Solution?

2011-02-19 Thread Matt Robertson

Here's the update:

Jochem's StAX-based solution worked so well -- and it allowed me to
re-use existing code since I was already processing xml -- that I
didn't bother to consider testing the xml2csv utility.

Original code processing a 45mb file yielded an insert time of 90
seconds per record with total file processing time being a projected
66 hours.

Using code that incorporated xmlSplitter.cfc, the routine created 2682
discrete xml files in approximately 45 seconds.  From there, the
insert loop did its work pulling out xml and pouring it into roughly
100 db table fields at ... 20 records per second.

Total time to read in the 45mb xml file, create the discrete files,
read them, insert them into the db and delete them (one at a time as I
went along in the loop) was 192250ms.

A bit more than three minutes.

Thats an acceptable level of improvement.

I owe you one, Jochem.

-- 
--m@Robertson--
Janitor, The Robertson Team
mysecretbase.com

~|
Order the Adobe Coldfusion Anthology now!
http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion
Archive: 
http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:342450
Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm


Re: Big XML files processing Really s-l-o-w. Solution?

2011-02-19 Thread Matt Quackenbush

Nice report!  I'll try and remember that the next time I have to parse huge
XML files.  :-)


~|
Order the Adobe Coldfusion Anthology now!
http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion
Archive: 
http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:342451
Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm


RE: Big XML files processing Really s-l-o-w. Solution?

2011-02-19 Thread Rick Faircloth

Nice...

-Original Message-
From: Matt Robertson [mailto:websitema...@gmail.com] 
Sent: Saturday, February 19, 2011 9:06 PM
To: cf-talk
Subject: Re: Big XML files processing Really s-l-o-w. Solution?


Here's the update:

Jochem's StAX-based solution worked so well -- and it allowed me to
re-use existing code since I was already processing xml -- that I
didn't bother to consider testing the xml2csv utility.

Original code processing a 45mb file yielded an insert time of 90
seconds per record with total file processing time being a projected
66 hours.

Using code that incorporated xmlSplitter.cfc, the routine created 2682
discrete xml files in approximately 45 seconds.  From there, the
insert loop did its work pulling out xml and pouring it into roughly
100 db table fields at ... 20 records per second.

Total time to read in the 45mb xml file, create the discrete files,
read them, insert them into the db and delete them (one at a time as I
went along in the loop) was 192250ms.

A bit more than three minutes.

Thats an acceptable level of improvement.

I owe you one, Jochem.

-- 
--m@Robertson--
Janitor, The Robertson Team
mysecretbase.com



~|
Order the Adobe Coldfusion Anthology now!
http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion
Archive: 
http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:342452
Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm


RE: Big XML files processing Really s-l-o-w. Solution?

2011-02-19 Thread Mark A. Kruger

Matt,

Very cool - an innovative approach I would not have thought of. Of course we
all know that Jochem's a certified genius :)

-Mark

Mark A. Kruger, MCSE, CFG
(402) 408-3733 ext 105
Skype: markakruger
www.cfwebtools.com
www.coldfusionmuse.com
www.necfug.com



-Original Message-
From: Matt Robertson [mailto:websitema...@gmail.com] 
Sent: Saturday, February 19, 2011 8:06 PM
To: cf-talk
Subject: Re: Big XML files processing Really s-l-o-w. Solution?


Here's the update:

Jochem's StAX-based solution worked so well -- and it allowed me to
re-use existing code since I was already processing xml -- that I
didn't bother to consider testing the xml2csv utility.

Original code processing a 45mb file yielded an insert time of 90
seconds per record with total file processing time being a projected
66 hours.

Using code that incorporated xmlSplitter.cfc, the routine created 2682
discrete xml files in approximately 45 seconds.  From there, the
insert loop did its work pulling out xml and pouring it into roughly
100 db table fields at ... 20 records per second.

Total time to read in the 45mb xml file, create the discrete files,
read them, insert them into the db and delete them (one at a time as I
went along in the loop) was 192250ms.

A bit more than three minutes.

Thats an acceptable level of improvement.

I owe you one, Jochem.

-- 
--m@Robertson--
Janitor, The Robertson Team
mysecretbase.com



~|
Order the Adobe Coldfusion Anthology now!
http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion
Archive: 
http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:342453
Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm