I’d definitely just use the ID to pull the user data. Here’s just one suggestion. Abstract the access to that data into a single location. If you’re writing OO, create an EmployeeFactory or an EmployeeService.getEmployee() method that returns a loaded employee object. Then if performance is an issue down the line, assuming your employee factory or employee service is an application scoped singleton (likely), you could do some app scoped caching in the factory where every time it gets an employee, it stores it in the variables scope of the factory/service effectively giving you application scoped caching. Then you could have some kind of simple garbage collector (if you have LOTS of employees so storing them all in app scope if a problem). Maybe you have a simple FIFO stack which holds n IDs and every time you exceed n you structdelete the n+1th ID from your cache. Then all you need is an isDirty pattern (http://www.pbell.com/index.cfm/2006/6/26/isDirty--Efficient-Caching) to handle when the data gets updated and needs to be refreshed (always a problem with caching).
But big proviso is you don’t want to do those kind of optimizations until performance becomes a problem. Just make sure you abstract creation into a factory so if you WANT to add caching later you only have to touch one method.
Best Wishes,
Peter
On 9/8/06 4:14 PM, "Hayes, Kyle D" <[EMAIL PROTECTED]> wrote:
Ok, that is what I figured you mean by persisting the data. I was stuck in the mindset and scope of my current project, which is why I asked for clarification. I am basically storing a record of type 'employee' which corresponds to the employee that is logged into the system. Their ID is provided via the corp wide login system. So I guess since I have that ID I can just call that record whenever I want to. I just wanted to minimize db calls whenever I could by storing the data in the session.
Kyle Hayes
Web Developer / Programmer
WebAID - Anaheim
Boeing Information Technology
714.762.2894
[EMAIL PROTECTED]
From: Peter Bell [mailto:[EMAIL PROTECTED]
Sent: Friday, September 08, 2006 12:11 PM
To: [email protected]
Subject: Re: [Reactor for CF] Serializing Reactor Records
And of course, I didn’t mention it, but you’ll want to store created and last updated information for all records and write a script to delete all old records based on some kind of business rules (anything from not updated for an hour if you’re looking to provide a session like experience to not updated for 2 months if you want to associate this to persistent login credentials – I have one system where users can log back in and see their most recent cart).
Best Wishes
Peter
On 9/8/06 3:04 PM, "Peter Bell" <[EMAIL PROTECTED]> wrote:
Hi Kyle,
It depends what kind of information you’re trying to persist and how secure it needs to be. A couple of common examples are persisting a shopping cart or persisting answers to a multi-screen wizard based form. Lets say you’re persisting a shopping cart, then you create a cart table and a cart_item table in your db with the appropriate fields. Every time someone does something to their cart you persist it to the database (add item, create cart, update quantities, etc.). To associate the user to the cart you could either use client variables (it’s been a REALLY long time since I even looked at those, but I’m actually pretty sure they depend on sessions, so I’m not sure they will solve your problem. Anyone who’s actually looked at them since 1999 please chime in here!) or using an ID you concatenate to all of your URLs and forms. Typically you’ll get your framework to just add a CartID to all URLs and to add a hidden CartID field to all forms.
Of course, if I want to have fun, I can change my CartID in the URL and have a look at other peoples carts, so typically in a real world scenario you’ll use the ID along with a seed and some encryption function to create a nice long string (or you could just use UUIDs) which you use to associate the user to the appropriate ID.
Feel free to let me know offline if you have more questions, we’re getting a little off topic here!
Best Wishes,
Peter
On 9/8/06 2:50 PM, "Hayes, Kyle D" <[EMAIL PROTECTED]> wrote:
Peter,
I appreciate your 2c, that is what I am looking for. And yes, we are switching to servers that are load balanced and the adminstrators would rather not do sticky sessions (which creates a sticky situation). Would you mind exanding on the specifics of persisting the objects in a database please? Thanks for your help!
Kyle Hayes
Web Developer / Programmer
WebAID - Anaheim
Boeing Information Technology
714.762.2894
[EMAIL PROTECTED]
From: Peter Bell [mailto:[EMAIL PROTECTED]
Sent: Friday, September 08, 2006 11:41 AM
To: [email protected]
Subject: Re: [Reactor for CF] Serializing Reactor Records
Hey Kyle,
Are you SURE you really want to do that?! I would consider using some kind of client key and just persisting the objects in a database. I know there is the performance cost of the db call for each page request, but compared to serializing and persisting objects (possibly with relationships) using client variables, I’d at least consider it.
Can I ask why you’re getting rid of session variables? I’m guessing it’s to move to a multi-server load balanced solution that doesn’t have sticky sessions, but if it is another reason and you’re using a single server, I might even consider persisting the data in application scope (with the appropriate garbage cleaning routines you’d need to write) before I serialized everything to client vars.
Just my 2c.
Best Wishes,
Peter
On 9/8/06 2:14 PM, "Hayes, Kyle D" <[EMAIL PROTECTED]> wrote:
Hey All,
I just got news that in my new project I am not going to be able to store data in session variables anymore and have to resort to using client variables. My question to you all, since I cannot store my reactor record objects inside a client variable, is there a serialize function or similar available to me to serialize the data inside an object and then eventually convert to wddx etc? Thanks.
Kyle Hayes
Web Developer / Programmer
WebAID - Anaheim
Boeing Information Technology
714.762.2894
[EMAIL PROTECTED]
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Reactor for ColdFusion Mailing List
[email protected]
Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Reactor for ColdFusion Mailing List
[email protected]
Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Reactor for ColdFusion Mailing List
[email protected]
Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Reactor for ColdFusion Mailing List
[email protected]
Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Reactor for ColdFusion Mailing List
[email protected]
Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Reactor for ColdFusion Mailing List
[email protected]
Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Reactor for ColdFusion Mailing List
[email protected]
Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
