Re: [Modeling-users] API cleanup proposal

[Sebastien B. <sbi...@us...>]

        Hi all,

  Got no answer for this; I guess this has already been enough
  discussed. Since the proposed changes is a subset of the initial one
  that everybody aggreed on, I'll apply them on thursday evening (ie in
  two days) --unless somebody comments further on this.

  I'll then make a new release.

-- S=E9bastien.


Sebastien Bigaret <sbi...@us...> writes:

>         Hi,
>=20
>   Time to summarize the changes we discussed here:
>=20
> EditingContext
> --------------
>=20
>   - insert() is an alias for insertObject()
>=20
>   - delete() is an alias for deleteObject()
>=20
>   - fetching: remove the need to import FetchSpecification and
>     Qualifier, and propose an alternate for
>     objectsWithFetchSpecification()
>=20
>        def fetch(self, entityName,
>                  qualifier=3DNone, # either a Qualifier instance or a str=
ing
>                  isDeep=3D0,       # should subentities be fetched as wel=
l?
>                 )
>=20
>     Note that parameters orderBy, limit/page/offset, lock and rawRows
>     have been removed since they are unsupported yet (they will be
>     introduced when support is available).
>=20
>   - make fetchCount() an alias for objectsCountWithFetchSpecification()
>       [same API as fetch()]
>=20
>   - make (set)autoInsertion() aliases for
>                             (set)propagatesInsertionForRelatedObjects()
>=20=20=20=20=20
>=20
> CustomObject
> ------------
>=20
>   - add globalID()
>=20
> KeyValueCoding
> --------------
>=20
>   - deprecate methods setValueForKey(), setValueForKeyPath() and
>     setStoredValueForKey()
>=20
>     I propose to set the removal time for these deprecated methods at
>     version 0.9.1
>=20
>   - add valuesForKeys(), counterpart for takeValuesFromDictionary()
>=20
>   Additionally, I propose to move the chapter dealing with KVC to an
>   other part in the User's Guide, in some 'advanced techniques' chapter,
>   so that it is not exposed as it is today.
>=20
> Validation
> ----------
>=20
>   No changes (because of backward compatibility issues, mainly)
>=20
>=20
> About the ``new'' KVC module:
> -----------------------------
>=20
>   Do we agree that it can be separatedly defined so that users can use
>   it as a mix-in for their classes, at their will? If so, does anyone
>   want to take the lead for this? (meaning at least continuing the
>   discussion and coming to a decision)
>=20
>=20
> Future enhancements
> -------------------
>=20
>   Interesting future features (NOT included in this proposal) have been
>   proposed in this thread, including:
>=20
>     - fetchSQL(): the possibility to pass a raw sql query to build
>       objects,
>=20
>     - the ability to fetch raw rows (i.e. raw dict) rather than
>       fully-initialized objects,
>=20
>     - fetchSummary(): adds access to sum()/avg()/... and group by/having
>       to the fetching API
>=20
>   We'll probably need to discuss some of these points a bit more,
>   however if you think you'll need one or more of these for the coming
>   releases please fill in a RFE on sourceforge's page and announce it
>   here --this is definitely the best way to make it happen sooner.
>=20
>=20
> I'd like to validate the API change proposal for the end of the week, if
> possible, so I'd appreciate if you could comment on this in the coming
> days. And BTW thanks a lot for the attention you already paid to this
> topic.
>=20
>=20
> -- S=E9bastien.
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Modeling-users mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modeling-users