Re: data source for “static” objects?
Re: data source for “static” objects?
- Subject: Re: data source for “static” objects?
- From: Chuck Hill via Webobjects-dev <email@hidden>
- Date: Sun, 7 Jun 2020 14:12:58 -0700
I’d guess that some still exist in Wonder in some way.
> On Jun 7, 2020, at 11:39 AM, email@hidden 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 <email@hidden
>> <mailto:email@hidden>> 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
>>> <email@hidden <mailto:email@hidden>>
>>> 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: email@hidden <mailto:email@hidden> t: (301) 956-2319
>>>
>>>
>>>> On Jun 7, 2020, at 12:37 PM, ocs--- via Webobjects-dev
>>>> <email@hidden <mailto:email@hidden>>
>>>> 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 (email@hidden
>>>> <mailto:email@hidden>)
>>>> Help/Unsubscribe/Update your Subscription:
>>>>
>>>>
>>>> This email sent to email@hidden <mailto:email@hidden>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (email@hidden
>>> <mailto:email@hidden>)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>>
>>> This email sent to email@hidden <mailto:email@hidden>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden