Comments on: ErlyDB 0.7

By: jwewymolusa

jwewymolusa — Sun, 10 Feb 2008 14:00:28 +0000

But then stopped, malin akerman nude that much longer, be doing your facts.

By: Norbert Klamann

Norbert Klamann — Fri, 30 Mar 2007 12:59:06 +0000

@arjw wrt. database independence.

IMHO not a great idea at all. Use the database to its fullest extent ! You never get as much security and performance for the buck as in the database itself.

[Disclaimer] I do Oracle DB-Development for a living.

By: Yariv

Yariv — Mon, 02 Oct 2006 12:09:13 +0000

Thanks for everybody’s input!

By: Yariv

Yariv — Mon, 02 Oct 2006 12:08:34 +0000

Regarding schema generation — it’s simple enough to do. Maybe I’ll try to hack something for the next ErlyDB release. About namespace collisions — I think the likelyhood of a collision is low enough for this to not be such a big concern. However, if it does happen, it can be annoying. I don’t see it as an urgent issue, but maybe I’ll find an easy way to add an ErlyDB prefix to generated functions for a future release. For hooks — you can call the is_new/1 function of the domain modules to check for INSERT or UPDATE statements in the before_save hook. In the after_X hooks, they always apply to a single record. If the DELETE or UPDATE statements don’t affect a single record, an error is thrown telling you how many records were affected in the database. Isn’t that sufficient?

By: Dmitrii Dimandt aka Mamut

Dmitrii Dimandt aka Mamut — Mon, 02 Oct 2006 02:48:22 +0000

One word: Whoah! Automatic table generation or table migrations (a la Rails?) could be a plus, though

By: ajrw

ajrw — Sun, 01 Oct 2006 23:53:50 +0000

Hm, clicking on the submit button seems to add a comment without giving any feedback (such as moving to a new page). Inappropriate use of Ajax? :)

By: ajrw

ajrw — Sun, 01 Oct 2006 23:51:27 +0000

Yariv: The nice thing about programmatic table creation is that you can write to one (common subset) schema and maintain portability across different database servers. There’s also the possibility for automatic database upgrades as new fields are added or existing ones are modified.

In particular I’m thinking of SugarCRM’s “vardefs.php” files, which define various metadata for each of the database (and virtual) fields, such as the column type and size. The field descriptor also covers things like formatting conventions, for automatic conversion from the user’s display/edit format to the database storage format - useful when handling lots of dates and currency amounts.

Perhaps this sort of thing would be better implemented as a layer over ErlyDB.

By: ke han

ke han — Sun, 01 Oct 2006 23:21:47 +0000

in addition to the resolution on save hooks, having access to information in the after hooks for fetch, save and delete would be useful. This additional info would inlcude the number of rows effected by the operation.

By: ke han

ke han — Sun, 01 Oct 2006 23:17:56 +0000

your before_save and after_save functions do not provide enough resolution. In many cases, you need to know if the save was an update or a create. I recommend either offering additional before_update, before_create, etc… or have an optional parameter to the save hooks to pass the context of the operation. You could have a before_save/2 which can be used like:
before_save(Model, Context) where Context == update.

By: ke han

ke han — Sun, 01 Oct 2006 21:52:41 +0000

Yariv,
I like where erlyDB is going. My biggest concern is namespace pollution. In anything but simple apps where your model objects are only used as rdb record wrappers, models end up with lots of functions for specialized domain behavior.
You are taking up lots of function names without having an approach for namespace collision. I assume you’ve thought of this and decided things looked more beautiful without prefixing functions with something like ‘_db_’, so you would have ‘_db_table’/1 or db_table/1 instead of table/1.