And thanks Chuck… Its a client with multiple apps and I was just trying to normalise things… Now I have a much better point of view for planning future actions…
:-) > On 22 Apr 2015, at 20:10, Gino Pacitti <[email protected]> wrote: > > Super… I was not looking at it from that point of view… thanks for the > clarification!!!!! > > >> On 22 Apr 2015, at 20:04, Dev WO <[email protected]> wrote: >> >> not only more generic, if you create a framework it is for code-reuse >> purpose. The actual execution of the software is done by the app, so the app >> is the part that need to have the relevant settings for it to run. >> Let’s illustrate that for a second: >> -you create a framework for managing customer and payment transaction >> -you develop a store app that you provide to multiple clients >> => Do you really want that all your clients have access to all customers and >> payment transactions?:) >> So what you do is that you change some settings at the app level (through >> different Properties file for each client or through client-specific launch >> argument for example) and deploy an app for each client, so each of them is >> isolated. >> >> Xavier >> >>> On 22 avr. 2015, at 20:54, Gino Pacitti <[email protected]> wrote: >>> >>> Ah… duh!!!!!!! >>> So leaving the connection dictionary and setting it in your app is much >>> more generic… :-) >>> >>> That is what you mean - right? >>> >>> >>> >>> >>>> On 22 Apr 2015, at 19:23, Dev WO <[email protected]> wrote: >>>> >>>> You’re missing something:) >>>> Your framework doesn’t need to be tied to a specific db (not even a >>>> specific db vendor). >>>> You usually left the settings/connection to the app itself through some >>>> Wonder properties: >>>> #dbConnectURLGLOBAL= >>>> #dbConnectUserGLOBAL= >>>> #dbConnectPasswordGLOBAL= >>>> etc >>>> When you create a “Wonder App” through Eclipse, you should get a bunch of >>>> properties available to you in Resources/Properties, check it out. >>>> >>>> Xavier >>>> >>>> >>>>> On 22 avr. 2015, at 20:19, Gino Pacitti <[email protected]> wrote: >>>>> >>>>> Ok, thanks for the clarification… >>>>> >>>>> Well if the Framework uses a single DB in the connection dictionary then >>>>> it seems to me that the pattern dictates that writing a record would be >>>>> to a single db and to a particular table. >>>>> >>>>> Or am I missing something really fundamental? >>>>> >>>>> I’m just trying to normalise my code into a Framework and write a record >>>>> independent of the App. >>>>> >>>>> >>>>> >>>>>> On 22 Apr 2015, at 19:06, Dev WO <[email protected]> wrote: >>>>>> >>>>>> EOF will take care of your primary keys/insertion without conflict. >>>>>> >>>>>> Despite the fact that you won’t have conflict, I don’t really understand >>>>>> why you would need 2 apps to write to the same db the same kind of >>>>>> object. I just don’t get it, but maybe it’s clear for you:) >>>>>> >>>>>> Xavier >>>>>> >>>>>>> On 22 avr. 2015, at 19:56, Gino Pacitti <[email protected]> wrote: >>>>>>> >>>>>>> Well if the Framework EOModel is tied to a single DB and set of tables >>>>>>> then all the Apps would be using the same data source. Obviously the >>>>>>> Apps would have different stacks and freshness would be an issue… but I >>>>>>> was more concerned with two records for the same DB and table being >>>>>>> created and saved. >>>>>>> >>>>>>> For example a payment system where more than 1 app might use the >>>>>>> Framework. >>>>>>> App1 needs to store a transaction ID in a TransactionObject and App2 >>>>>>> needs to store a transactionID in a Transaction Object. These objects >>>>>>> which have TempGlobalIDs have not been saved as yet but the moment one >>>>>>> is saved the EO_PK_Table is updated with a PK for the >>>>>>> TransactionObject. But then if the other TransactionObject is attempted >>>>>>> to be saved what would happen… would there be a conflict or as you say >>>>>>> are they completely independent and the EOF would handle it and save >>>>>>> the other TransactionObject with a non conflicting PK? >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 22 Apr 2015, at 18:40, Dev WO <[email protected]> wrote: >>>>>>>> >>>>>>>> Assuming you have a specific db for each app of course. If not, the >>>>>>>> objects are still all independent, but you’ll have to deal with data >>>>>>>> freshness/communication between the 2 apps as they would access the >>>>>>>> same storage. >>>>>>>> >>>>>>>> Xavier >>>>>>>> >>>>>>>>> On 22 avr. 2015, at 19:42, Gino Pacitti <[email protected]> wrote: >>>>>>>>> >>>>>>>>> Ah Ok.. so even if 10 apps use the same Framework every EOObject is >>>>>>>>> completely safe and no conflicts for PKs… >>>>>>>>> >>>>>>>>> Great... >>>>>>>>> >>>>>>>>>> On 22 Apr 2015, at 18:36, Dev WO <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> Hi Gino, >>>>>>>>>> >>>>>>>>>> Everything is completely independent. >>>>>>>>>> No conflict. >>>>>>>>>> That’s actually why you create frameworks;) >>>>>>>>>> >>>>>>>>>> Xavier >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 22 avr. 2015, at 19:17, Gino Pacitti <[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>> I was planning a Framework which has an EOModel that two different >>>>>>>>>>> apps will use. Is there a potential of conflicts when each app >>>>>>>>>>> tries to create a record and save to db? >>>>>>>>>>> >>>>>>>>>>> Specifically if app1 creates an EOEnterprise Object and modifies it >>>>>>>>>>> and does not save and at the same time app2 creates an EOEnterprise >>>>>>>>>>> Object and does save… Does the Framework follow the creation of >>>>>>>>>>> TempGlobalIDs and does not allow conflicts to occur when that >>>>>>>>>>> Framework is being used between apps? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>>>>>> Webobjects-dev mailing list ([email protected]) >>>>>>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/webobjects%40anazys.com >>>>>>>>>>> >>>>>>>>>>> This email sent to [email protected] >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>>>> Webobjects-dev mailing list ([email protected]) >>>>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/webobjects%40anazys.com >>>>>>>>> >>>>>>>>> This email sent to [email protected] >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>>> Webobjects-dev mailing list ([email protected]) >>>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/ginokris%40me.com >>>>>>>> >>>>>>>> This email sent to [email protected] >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>> Webobjects-dev mailing list ([email protected]) >>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/webobjects%40anazys.com >>>>>>> >>>>>>> This email sent to [email protected] >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Do not post admin requests to the list. They will be ignored. >>>>> Webobjects-dev mailing list ([email protected]) >>>>> Help/Unsubscribe/Update your Subscription: >>>>> https://lists.apple.com/mailman/options/webobjects-dev/webobjects%40anazys.com >>>>> >>>>> This email sent to [email protected] >>>> >>> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/webobjects%40anazys.com >>> >>> This email sent to [email protected] >> > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/ginokris%40me.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
