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