Monday 12 March 2007 12:25:03 am
<i> > Hi kracker, Thanks for the reply.</i> No worries <i> >> I can't explain it but I know it's (data_text_2) reserved for future use to store extended information (perhaps similar to data_text_1) related to the order.</i> <i> > Pretty cryptic :) Can you explain where you have received this information from or elaborate at all? </i> Sadly I can not. I know I read a lot of obscure details in the code and in conversation. I'm sure others can relate to not really knowing why they know something obscure ... If I was to try to find more on this answer I would have to spend a lot of time back tracking through various public resources :\ <i> > I've considered and discounted storing the info in data_text_1 as I'm using that for the account info and it doesn't make sense (to me at least) to mix this information.</i> Except that you over look the notion that the shop_account handler xml stored in data_text_1 is self contained. Meaning you can store say a second shop_account handler xml document (also still both self contained and separate) within the data_text_1 attribute. So ... they don't mix. Or at least that was the idea at the start of the thread ... They might share a storage location but this still seems to provide for a stack of separate sets of information (the same you want to store in data_text_2) can be stored in data_text_1 without causing conflict with existing classes which depend on this attribute data_text_1. I'm ready to be wrong :\ <i> > I was considering using data_text_2 to store the info encapsulated in XML with associated metadata( date, time etc) - this would allow for multiple transactions. Creating a table & a persistent object class is also an option I've considered.</i> But fetching information from this location (multiple transactions) prolly means parsing a lot of xml to simply get to the information surrounding storing variable content inside of xml inside of data_text_2 (or any). It's a number of layers and I think Paynet does this very much differently (if that is any guide) ... <i> >> Where doing this inside of ezorder has inherent limitations...</i> <i> > Aside from the data_text_2 being reserved for future use, what limitations are you aware of?</i> I see none. I think would be perfectly acceptable for a one off implementation, it might not ever become a real problem. <i>//kracker Modest Mouse - Never Ending Math Equation</i>
Member since: 2001.07.13 || http://ezpedia.se7enx.com/
|