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 11:06:32 -0700
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> 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