I’d guess that some still exist in Wonder in some way. > On Jun 7, 2020, at 11:39 AM, o...@ocs.cz wrote: > > Chuck, > > thanks a lot, sounds hopeful :) > > Will check. Should you happen to have a link to some sample code at hand, I'd > be grateful; otherwise of course I'll search for it myself :) > > Thanks again, > OC > >> On 7. 6. 2020, at 8:06 PM, Chuck Hill <hill.ch...@gmail.com >> <mailto:hill.ch...@gmail.com>> wrote: >> >> I think what you want is to subclass EOAadptor, EOAdaptorChannel, and >> EOAdaptorContext and have them talk to your Java classes. The layer above >> (EODatabase etc) can stay are they are. >> >> There have been flat file adataptors, screen scrapers etc. I don’t see why >> what you want could not work. The model the entities are in control the >> EOAdaptor used. >> >> Chuck >> >> >>> On Jun 7, 2020, at 10:02 AM, Aaron Rosenzweig via Webobjects-dev >>> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >>> wrote: >>> >>> Hi OC, >>> >>> I suppose you could move your java POJOs into a .jar and then expose them >>> with a java app running on a particular port that masquerades as a DB >>> endpoint. I’m not sure it’s worth the trouble but it could be done. This >>> would be the “my DB in a box” solution where you essentially make trimmed >>> down DB server that doesn’t allow updates but allows SQL queries. It gets >>> weird though with EOF and honestly I’ve never tried jumping DBs for foreign >>> keys. I’ve only used multiple DBs to do queries on unrelated data. >>> >>> I assume you like how handy it is to have the java classes at your finger >>> tips and able to edit them when needed but you also like to be able to >>> query in SQL for various attributes that those POJOs have… so you go to the >>> trouble of making an EO doppelgänger that you have to sync. >>> >>> Perhaps you can make your POJOs enums? If that’s feasible then you could >>> use the enum prototype in your EO so that instead of having an FK it is an >>> attribute of an enum type. >>> >>> If enums are not feasible then maybe you should stop thinking of them as >>> POJOs and make them EOs which you have to change via SQL migrations instead >>> of twiddling java classes. That would be the path of least resistance. >>> Since they are pretty much read only, you could consider making them shared >>> Eos but it’s not mandatory to do so. >>> AARON ROSENZWEIG / Chat 'n Bike <http://www.chatnbike.com/> >>> e: aa...@chatnbike.com <mailto:aa...@chatnbike.com> t: (301) 956-2319 >>> >>> >>>> On Jun 7, 2020, at 12:37 PM, ocs--- via Webobjects-dev >>>> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >>>> wrote: >>>> >>>> Hi there, >>>> >>>> let me please ask another weird question. For the context, thing is, one >>>> of our applications supports “predefined” EOs -- things like static lists >>>> and similar. In our case, they are completely defined in the Java code -- >>>> the number of them, all their attributes, whatever. Then, runtime, they >>>> are shared for all users/sessions/editing contexts. >>>> >>>> Since they need to be real EOs (they mix with normal dynamically defined >>>> objects, they are part of relationships, etc), it brings non-trivial >>>> problem how to implement the stuff. >>>> >>>> At this moment, we >>>> - at launch, synchronise these objects into the database: if the Java code >>>> defines a new object which has not been there, it is inserted; if there >>>> are changes in attributes, they are updated. If an object of this kind is >>>> found in the database and there's no description for it in the Java code, >>>> it is deleted; >>>> - then we load them into the shared EC for all users to share them. >>>> >>>> It works, but the synchronisation approach is ugly; it feels sort of wrong >>>> to keep copies of those static objects in the database. >>>> >>>> Now, I wonder: EOF does support multiple data sources. How difficult and >>>> error-prone would it be to implement my own data source, which would -- >>>> instead of from a DB -- “load” objects from the application predefined >>>> code? Would it be possible? Wouldn't it bring more problems than the old >>>> code did? To illustrate the idea, here's the notorious Apple pic, tweaked >>>> appropriately: >>>> >>>> <canThisBeDone.jpg> >>>> Has anybody out there already tried something like that, and if so, with >>>> any luck? >>>> >>>> Thanks, >>>> OC >>>> >>>> >>>> >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >>>> <mailto:Webobjects-dev@lists.apple.com>) >>>> Help/Unsubscribe/Update your Subscription: >>>> https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com >>>> >>>> <https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com> >>>> >>>> This email sent to aa...@chatnbike.com <mailto:aa...@chatnbike.com> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >>> <mailto:Webobjects-dev@lists.apple.com>) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/hill.chuck%40gmail.com >>> >>> <https://lists.apple.com/mailman/options/webobjects-dev/hill.chuck%40gmail.com> >>> >>> This email sent to hill.ch...@gmail.com <mailto:hill.ch...@gmail.com> >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
