Re: [gentle-devel] Broker interface

[Morten M. <mo...@me...>]

Hi Martín,

see my other mail for some general feedback..

> I'd mix Generic-NonGeneric but that's just me; or perhaps leave 'em
> internally separated, but provide an "easy" aggregation that Mixed 'em
> all into a single IUpdateWithAndWithoutGeNeRiCs,
> IPeRsiStWithAndWIThoUtGeNErICS. (using the funky names is a plus too)
lol.. why not take the full step and use IL33t and such instead. Is
great fun in a case sensitive language ;)

>> o Are the current interface definitions "feature-complete"? Can you
>>
> Since I honestly haven't taken a deep look at G2 yet (I am not using
> .NET2 yet) I cannot think of a specific scenario.
Well, it's not really G2 specific. What would like to ask your ORM in
terms of persistence tasks? Since this is the main access point into
Gentle, it should provide all the functionality and flexibility that
users will need.

>> o Should there be separate classes for working with and without
>> generics, or should all methods be exposed by a single class?
>>
> I think that the only way to answer that is to put it the other way,
> kind of: where or why would I need a Generic and Why not?
I'm afraid that lessons on C# language fundamentals is beyond the scope
of this discussion ;) but do see the comments in my previous mail.

>> o How many convenience overloads do you think are warranted? There seems
>> to be an awful lot of RetrieveInstance and RetrieveList methods.
>>
> True, although that doesn't hurt, unless you add too much complexity.
> In Gentle 1, there are a bunch of Overloads that are never used (at
> least by me - which doesn't mean anything-; despite that, i don't mind
> having them there).
Agreed.. one thing I've considered is, will people still want to use the
Key class to specify a number of column constraints that are to be ANDed
together? These methods are essentially a port of the way G1.x allowed
you to request things, and are technically no longer needed, given that
the same and much more can be expressed using the LogicalExpression
class. My current inclination would actually be to drop them, although
it wouldn't save more than a few lines of code.

>> o Good names for the new GentleSession/PersistenceBroker class(es). If
>> nothing else comes up I'll most likely rename GentleSession back into
>> PersistenceBroker (or maybe just Broker?) before release.
>>
> The usage of GentleSession is not as good as PersistenceBroker for
> many reasons. One of them is: we're used to PB ;)
> But then GentleSession sounds too much GentleRelated (which is not
> bad) but Session sounds good! Because it's a session.
> How about PersistenceSession ;)

Using the term Session only makes sense if there is some sort of session
concept involved. Currently, there is no such thing. It's just a request
interface associated with a provider.

That said, I think object caching and uniqing should be tied to a
GentleSession. This would obsolete the need for the UniqingScope, since
the cache scope would be controlled by how many GentleSession objects
you create and use. However, this bit needs more thought and I'm not
quite ready to deal with caching yet :)

>> o Are the names Retrieve/RetrieveList/Persist/Insert/Update/Delete good
>> names? Should we use Save/Load/Remove or some such instead?
>>
> I'd stick with:
> a) What is known (Persist, Insert, etc) for Gentle 1 users. (but
> that's just me)
> b) What is more "logical". Even when the ORM is "hiding" the database
> magic behind the scenes, I'd keep the "worldwide known" terms.
Save and Load are not universal terms? ;) .. well, if no-one has any
complaints over the current naming scheme then I agree that we should
just stick with those. I do like short names though, and
RetrieveInstance is a bit.. well, not short :)

> Off Topic: Are you thinking of the possibility of "serializing" the
> ObjectMap that the analyzer produces (xml?) and then load it "on the
> fly" ?
No :)

Once 2.0 has been released, bugfixed, and the main providers have been
ported, then perhaps such performance optimizations might start to move
up the todo list, but currently it is not something I think about..

That said, this is an open source effort and people are free to
contribute where they feel the greatest need at any given time :-)
> I know that for ASP apps this is a minor issue (startup time is just
> hidden from the user which will refresh as many times as needed until
> the application starts) but for Window.Forms applications, reanalyzing
> a DBScheme everytime is not very nice (nor needed if you think of it).
> If you are interested in this, I'd enlist as a candidate to help with
> the task, since I am most interested in it. I am not talking about
> (why not) replicating NHibernate feature of storing the whole scheme
> on a hand-made XML. I'm merely thinking of gentle doing something like
> this:
>
> - I have to analyze. Do I have (a file or received by param) an XML
> scheme?
> - Yes: Load it and go on.
> - No: Analyze, Save To File (if configured to do so), Go On.
>
> If the DB Changes, I could force an analysis or stuff like that.
Sounds more than reasonable. I'd suggest using IsolatedStorage for
caching the metadata classes. Metadata for schema information is found
in the IGentleProvider.MetadataRegistry. Mapping information (structures
tying schema metadata to member metadata) is found in
IGentleProvider.MappingRegistry (member metadata uses classes from
Gentle.Reflection).

In order to provide an XML configuration facility (such as the one
NHibernate has) you'd need to implement the
MappingRegistry.UseXmlMetadata method and extract information similar to
what the UseAttributeMetadata method does. Some refactoring to support a
pluggable source might be a good idea (e.g. by passing in a
IMetadataProvider to a generic UseMetadata method, and put the code for
handling a specific source in implementations of the IMetadataProvider
interface).

I'd be happy to merge code for either one of the two things above, but
I'm not going to write them myself.

>> o Transactions across multiple requests are not possible (need extra
>> parameters/methods for this).
> I'd be lovely if this were possible. We (ab)use a lot of transactions
> here.
One thing at a time - can't solve all problems at once :)

Yours,
Morten