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/archive%40mail-archive.com This email sent to [email protected]
